LNET TCP, how do I know the server side is ready to recieve again?
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
MaartenJB · 2013-07-11 15:40

Hi,

I’m building a TCP client server application with LNET. Sending data
works just fine. The thing I noticed is that the “CanSend” event is
triggerd on the client side, even if the server side is still
receiving data.
Do I need to implement some sort of ready to receive message myself or
is there a build-in solution already there?

Thanks

----------------------------------------------------------------------
goodname · 2013-07-11 18:24

CanSend is triggered when the client is ready to send more information
packets. It does not know what is going on on the server side. The
server takes packets as they come in and rebuilds it back in the
correct order using the TCP protocol. The server does not know what is
going on on the client side.

http://lnet.wordpress.com/usage/sockets-protocols-and-sending/

----------------------------------------------------------------------
MaartenJB · 2013-07-17 15:11

Hi,

Thanks for the info! I've added an EOF to my data stream, it's working
fine.

Maarten

----------------------------------------------------------------------
goodname · 2013-07-17 23:16

Good to hear it worked.

An EOF sounds simple but there is no ASCII character called EOF.
Suggest using a End of Transmission(EOT) or End of Text(ETX) which are
ASCII characters.

Another method is to base64 the data before sending and use a non-
base64 character as the end marker.

The "How do I know when my data stream has ended?" is a reason people
often use http which automatically takes care of this information in
the form of a known data length.

----------------------------------------------------------------------
MaartenJB · 2013-07-22 20:28

Hi,

Thanks for the info, I did not know there was such thing as a EOT or
ETX character. I'm sending jpgs over the tcp stream. Using your
suggestion base64 with an end marker is probably the best thing to do,
but I've tried it and noticed that it comes with a small performance
penalty. Normally this would not be a problem, but in my case it is.

So my solution for it is not very neat but it works for now, using a
multi character as an end marker.

----------------------------------------------------------------------
ludob · 2013-07-23 05:46

The safest and fastest is to put a fixed 4 bytes block containting the
length of your data in front of your image data. So the other side
knows from the first block how many more data it will receive and no
parsing is needed to detect EOF. It also allows you  to allocate the
memory immediately for receiving the image data.

----------------------------------------------------------------------
MaartenJB · 2013-07-23 14:15

Yes, that's a good option. I've thought about that too, don't remember
the reason why I did not choose to use that option.....

----------------------------------------------------------------------
MaartenJB · 2013-07-24 09:41

Build in an Int64 header, works superb.

Thanks!