You must be logged in to post Login

Lost Your Password?

Search Forums:


Wildcard Usage:
*    matches any number of characters
%    matches exactly one character

TCP: mTotalBytesReceived > mMessageLength

No Tags

10:12 am
January 8, 2012



posts 49

From Robert:

I have encountered a problem with the TCP version. In TcpServer.OnDataReceived, when mTotalBytesReceived > mMessageLength an assertion is invalidated. I’m not sure why you assume that mTotalBytesReceived always will be equal to or less than mMessageLength, since it might as well be more (which should be fully valid), in which case you should remove the message and then save the extra data for the next message?

Hello Robert,

I'm quite confident that that code is correct — from Bespoke Osc transmitter to receiver — but, if you're using a 3rd-party Osc transmitter, then both sides of the connection have to send/receive byte arrays in the same fashion. Let me explain.

The mTotalBytesReceived variable refers to the amount of data read from the active connection and accumulates "per chunk". With TCP (unlike UDP) messages can span multiple BeginReceive/EndReceive callbacks. This variable gets reset, once all chunks have been read, to setup for the next message.

The mMessageLength variable refers to the amount of data "claimed" to have been encoded in the entire message. Specifically, the OscPacket.ValueToByteArray() method writes the length of the byte array and then the byte array iteself. This is what the mMessageLength == int.MinValue stuff is all about — I'm looking for the first chunk of data, to then read and decode the first 4 bytes as the encoded message length.

With these descriptions in mind, it's certainly valid to assert that mTotalBytesReceived should never be > mMessageLength. So, your next question might be, why did I do this?

Answer: I wanted some sanity checking — particularly useful when considering endian swapping between dissimilar architectures on the two endpoints of the connection. If the data being exchanged is in opposite byte order, you'll notice a whacky mMessageLength value — which I find helpful. This is less necessary for UDP, because messages are fully encoded in a single datagram.

So, why might you have trouble with this implementation. 1) If you're using a 3rd-party Osc transmitter, it may not be (likely won't be) encoding the first byte as the total message length. This will completely screw up the message read by the Bespoke TcpServer/OscServer. 2) The 3rd-party Osc transmitter is encoding the first byte as total message length, but is doing so in the opposite endian that's set for your TcpServer/OscServer.

If it's the second issue, that's easily addressed by toggling the OscPacket.LittleEndianByteOrder property. If it's the first issue, you'll either have to make the 3rd-party transmitter encode the first byte as the total message length, or you'll have to modify the Bespoke TcpServer to not care about such information. As an open-source project, you're welcome to make any changes to the Bespoke Osc Library you'd like.

If you have any questions, just shout.




10:32 am
January 9, 2012


New Member

posts 1

Post edited 10:36 am – January 9, 2012 by ronag89

I've changed the code in TcpServer.OnDataReceived to work properly with how TCP behaves.

Note: You have to inclue System.LINQ to have it compile.

Great library otherwise!

No Tags

About the Bespoke Software forum

No Comment

Comments are closed.