Custom Variable Length Binary Protocol

Apr 27, 2012 at 5:38 PM

I'm attempting to use SuperSocket with my own custom variable length protocol.  I prefer to use a state machine to process the incoming buffers, but I'm running into a problem.  I would like each of my states to be responsible for parsing a certain portion of the packet.  I also strongly prefer to process one state per call to FindCommandInfo.   In my case, the first state, simply waits for a start character while the second waits for the fixed length header that has the length parameter.  At the moment, I have each state read the number of bytes it needs to do its job and set the out left parameter to the readBuffer length minus the number of bytes that was just processed.  In the case of my first intermediate steps, I then return null because I have not gotten enough information to process a packet yet.  It appears to me that the out left parameter is only doing anything when I return a command other than null.  Even though I have told it I have not processed all of the bytes in the read buffer, if I return null (no command yet), then it never goes back into the FindCommandInfo function until more data arrives, and then I only have the new data that was just sent (not the leftover data).  Is this expected behavior or a bug?  


Here is the code I have written if it helps illuminate what I'm attempting to do.  I'm also open to alternative suggestions as well to accomplish the same thing:

Apr 27, 2012 at 6:39 PM
Edited Apr 27, 2012 at 7:19 PM

Here is a (preliminary) modification to AsyncSocketSession.cs that appears to accomplish what I'm after.  Not sure how much else it breaks at this point, but my tests so far are working.


The changes are lines 21 - 29.

Apr 28, 2012 at 2:38 AM

No, you needn't do it like that.

If you set left > 0, the find command will be executed again before the other bytes received.

The sample project "CustomProtocol" in QuickStart demonstrates how to implement a variable length protocol.


May 7, 2012 at 6:23 PM

You are correct that I do not need the modification I mentioned earlier since the ProcessReceive method in AysncSocketSession.cs has:

while (bytesTransferred > 0)

bytesTransferred = left;

The problem is that in that loop, the method exits if the FindCommand method returns null.  I do not believe I can use the methodology used in your examples to process my custom protocol.  Instead, I prefer to use a state machine to reliably parse the various segments of my incoming packets.  The cleanest way for me to accomplish this is to have the FindCommand function continue to be called as long as left > 0, even while FindCommand returns null.  As it is now, the left parameter is only good for preserving the bytes that are the start of the next command.  If you do not return a valid command (because you are still in the middle of determining the command), even if left > 0, the FindCommand method will not be called until new data comes in on the port.



May 8, 2012 at 12:52 PM

You can do it by yourself in the class of your command reader.

May 18, 2012 at 11:32 PM
Edited May 18, 2012 at 11:59 PM