You mean Nadle’s algorithm? That might produce individual packets but it depends on payload size and congestion/scheduling can still mean that the other side gets both sends as one receive. You really should create a messaging protocol if you need to receive individual packets separately.

THX for replay. My project is to communicate with an embedded device that is already set to TCP, but whose instruction format is a message, not a stream. So I can only look for a compromise. It is not known whether the “nodelay” parameter is useful.

Can be set TCP_NODELAY with tcpserver？

TCP does not support “messages”. That is anything you send via TCP is part of the same stream of bytes. You will need to make messaging work yourself by using a higher protocol or implementing something like count bytes at the start or a separator sequence.

I see…
Thanks a lot for your reply!

You want me to send you the code?
Please add a workaround for this case either inside the library, or let me send you mine. It was a major hassle to figure it out, especially because Windows CE is really limited in regards of debugging and as I said the company behind it was also uncooperative.
It was the Datalogic scanner model “Memor”. The revision called “X3” has a few other CE bugs already (GUI related) and this error happens way way way more often on the hardware revision than on the original Memor hardware. We weren’t able to use the X3 model until I finally figured it out, because even the short delay did only sometimes fix it. Depending on the network connection it didn’t really help, which is why I looked into it once again in 2019.

Wow that’s quite a find! Glad it worked out in the end.

I left a message on here some time ago.
I finally figured out the UNDERLYING problem of it.

The problem is that on these Windows CE scanners the messages are not in the right order. It seems to happen when the network connection is too fast. It’s quite obviously a network driver/Windows CE bug, but the company behind them told me that they don’t really care about fixing it, because the CE Internet Explorer works with it.

You get a data received message before the connection established messages arrives.
That makes the data received message get discarded and thus the FTP startup is ignored, which then makes the program wait endlessly.

I added a boolean, where I remember that data has arrived and I check that boolean right when connection established was received and then act on it.

This solves the problem 100%. I can send you the code if you want me to.

Kind Regards