Incoming data should always be parsed be the command, NOT by the packet. Reason being, commands can be sent across multiple packets; both by the client and server. It is possible to just split the data with deliminator \r\n (vbCrLf) and loop through it, but it would just make unnecessary hard work when it comes to payload commands.
A payload command is a command with additional data, which is usually spanned across multiple lines, after the initial command line. For example:
MSG someone@hotmail.com Bobby 120 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22 Hello!
The first line is the main command, and the rest of the data is the payload data. The last parameter in the command indicates how much payload data follows. This is where putting the Winsock buffer to good use can make things simpler. When used properly, the Winsock control can be very good; the three main things I want to look at are the functions GetData, PeekData, and the event DataArrival. The event DataArrival is raised whenever the socket receives data and the parameter BytesTotal indicates how much data was received in the packet. Instead of removing that data from the Winsock buffer as soon as it’s received, you should see what is it first without removing it. This can be done with the PeekData function; PeekData is pretty much identical to the GetData function, except it doesn’t remove the data from the buffer.
If there is no new line in the buffer, then you should just exit the procedure, because not all of the command has been received, and the next DataArrival should take care of it. If there is a new line, then the first 3 bytes of the buffer should be checked, if it’s a normal command, then remove only the length of that command from the Winsock buffer, which would be the position of the first new line. If these 3 bytes are a payload command, then get the length of the payload data from the last parameter. Check if all the data has been received by comparing much data is in the Winsock buffer against the command length and the payload data length. If it is equivalent to or more than the last parameter, plus the length of the command (which would be the position of the first new line), then all of the data has been received. Remove the length of the command and the payload data from the buffer, if it’s less, leave it, and let the next DataArrival handle it.
You would need to loop until the buffer is empty (BytesRecieved = 0), or exit the loop when not all the data has been received as stated above.
You must handle all payload commands properly, if a client that is unprepared to handle one, then it is likely to crash. The payload commands are as follows, not all are receiving ones.
- MSG – Messages
- QRY – Challenges
- PAG – Send messages to a user's mobile device
- NOT – Notification of some event
Download: prjDataHandlingExample.zip
0 Response to “Data handling”