I have developed a protocol for a Client-Server application and developed it in conjunction with another developer. The client application at this moment is written for the mobile phone.
The protocol uses comma separated fields with start and end deliminators. Because some of our fields are free form ASCII text we are byte stuffing the fields so that special characters can be handled within and not mess up our data parsing.
The problem is that one field has been byte stuffed when it shouldn’t have been. The field in question was to represent coordinates i.e.
<rest of data packet>, <lat>,<lng>,....
where
<lat>: Latitude coordiantes i.e. -37.6543
<lng>: Longtitude i.e. 90.8993
However what we I recieved on the server was the byte stuffed character for a comma appearing in the dot field i.e. -37^-6543. This in turn caused the server to ignore the packet and not record the details.
Reason:
When I mentioned this to the phone developer he said it was because the character settings on the phone meant that the user had changed the dot to a comma. It was his belief that we should handle this on the server. However I’m not sure. I have a thought that clients should follow the protocol as in theory there could be different clients connecting and the server doesn’t want to have special cases littered in it’s code base?
Question:
So some options I see are (and I’m not sure how to approach this):
- Get all clients to send the data as per for the protocol spec and keep the data format black and white so to speak
- Have the server handle a variety of options in this case
- In conjunction with 2 adjust the protocol document so that data is more flexible in some cases and the server is responsible for handling the different cases
So the question is: should you change the protocol to be more flexible (allowing variations of the format), or should the clients adhere to what you currently have?
I don’t think there is a one size fits all solution here, the answer is totally up to the parties involved to negotiate. All have to agree on the protocol (the current one or something more flexible), and then all client applications must implement it correctly otherwise they cannot expect the server to handle malformed requests well.
That said, it seems reasonable to expect clients to implement the -37.6543 format instead of using byte stuffing as -37^-6543. I think the client should handle this and you should keep your current protocol.
0