You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i found your tutorial, and only want you give some hints for your future tcp experience.
On reading data from a tcp socket - you should never expect to read one message.
It can always happen that you read only a part of it, or multiple...
This happens in real world scenarios were TCP split the data on the lower layer.
This "Framing" comes from Serial-Line Communication. On TCP you can expect that never any data gets lost. So you can make it simple.
On read you can read until such a char ... handle this in your routing.
And then handle the data following the End Marker -
or wait for more data.
Another way is some kind of LV-Encoding (Length,Value). Here you send the length of the frame as first data.
So Client read exactly this number of bytes, and then expect a length again.
This is only minimal examples , to show the concepts... ;)
Good Luck and I wish you much fun with creating new protocols. ;)
The text was updated successfully, but these errors were encountered:
Thanks for the feedback, really cool. Yeah, this was more of a quick hacky way of doing a protocol because it was made for a college class more than anything haha.
Appreciate the input, I thank you for taking the time to explain this to me and might try to implement this into the project someday :)
Hello,
i found your tutorial, and only want you give some hints for your future tcp experience.
On reading data from a tcp socket - you should never expect to read one message.
It can always happen that you read only a part of it, or multiple...
This happens in real world scenarios were TCP split the data on the lower layer.
Perhaps you should define a Start or Stop Char.
Some Protocols like SMTP use \r\n. As End of Message Marker
Other Use binary chars like 0x01,0x02 - with quoting this in the Message.
( Sample is BER which use additional Tag identifier https://www.oss.com/asn1/resources/asn1-made-simple/asn1-quick-reference/basic-encoding-rules.html)
This "Framing" comes from Serial-Line Communication. On TCP you can expect that never any data gets lost. So you can make it simple.
On read you can read until such a char ... handle this in your routing.
And then handle the data following the End Marker -
or wait for more data.
Another way is some kind of LV-Encoding (Length,Value). Here you send the length of the frame as first data.
So Client read exactly this number of bytes, and then expect a length again.
This is only minimal examples , to show the concepts... ;)
Good Luck and I wish you much fun with creating new protocols. ;)
The text was updated successfully, but these errors were encountered: