Page 1 of 1

What are the extra bytes in TCP socket messages?

Posted: Tue Apr 11, 2017 6:39 am
by gregfjohnson
I would like to use wx sockets to interface to another external TCP server. I am using the wxLua wrapper for wxWidgets.

I used the simple client.wx.lua program, and set up a separate server that prints packets from clients.

When I send "XXXXYYYYZZZZ" from the wxWidgets client program, I get the following string at the TCP server:


If I send "abc" I get the following string:


What are the initial eight bytes and the final eight bytes in the above TCP messages?? It looks like byte 5 is the length of the actual message

Would it be easy or hard to update the external TCP server that I am trying to talk to so that it could exchange TCP data with wxSockets?

Is there any way to configure wxWidgets sockets so that I do not get the extra 8 bytes at the beginning and end of every TCP message?


Greg Johnson

Re: What are the extra bytes in TCP socket messages?

Posted: Tue Apr 18, 2017 1:11 pm
Hi, Greg,
You need to talk to people that developed/maintain that TCP server.
We do not know what protocol it uses and how it communicates with the other world...

Thank you.

Re: What are the extra bytes in TCP socket messages?

Posted: Mon May 01, 2017 5:50 am
by gregfjohnson
I realized the problem. I was mistakenly using the method wxSocketBase::WriteMsg(). As the documentation notes:

"WriteMsg() sends a short header before the data so that ReadMsg() knows how much data should be actually read."

This "short header before the data" is what I was seeing when I sent a TCP message from inside wxWidgets to my external server.

(The problem was not with the external server, but rather it was the header data being added by wxWidgets in its WriteMsg() method.)

The solution was to use wxSocketBase::Write(). This way, wxWidgets just sends the bytes I give it, and does not add the header.

On the read side, wxSocketBase::Read(), I needed to attempt to read more bytes than the longest message I expect. wxWidgets
counter-intuitively returns that number, no matter how many bytes were actually read. After the Read(), you can call LastCount() to find
out how many byte really were received off the wire by the Read() operation.