SBL2e dividing serial messages on TCP

[Foxtron]

I use the chip SBL2e for serial to TCP converter. I'd like to make the converter to send all serial data in one TCP packet. Protocol is Modbus TCP - my PC is a Master, the serial device behind converter is a Slave. Maximal length of my serial messages is 50 characters. Characters are sent without spaces. Parameters of serial are as follows: 19200,8,E,1
I've set custom serial packetization options:
Number of characters to accumulate before sending TCP/UDP packet: 512
Number of milliseconds to wait for accumulated characters: 100
Flush TCP/UDP frame when this character is received: N/A
According to my opinion it should send whole message in one TCP packet, but it very often divides messages to two TCP packets of various length. Why? Thanks for your help in advance.

[rnixon]

TCP is a stream protocol, which means there is never any guarantee what will be in a specific packet - but there is a guarantee all data will be delivered or your app will be notified of a timeout. You can almost think of it as a serial port stream of data. Whatever code you are writing needs to be mindful of start and end of message.

[Foxtron]

Thanks for the answer. I supposed it. The problem is, that Modbus protocol isn't ASCII and doesn't use start and stop characters. But I have already solved it in SW. I only hoped that custom packetization helps me. For monitoring of ethernet communication I use wireshark. It is very sophisticated programm. It recognizes Modbus TCP communication, but it has problem with dividing Modbus TCP packets. I can compare the behaviour to Korenix S2E convertor and it doesn't divide the packets.

[Foxtron]

I understand the dividig of packets is not a fault but a feature. But unpleasant feature. If some feature is named: custom packetization, I'd suppose it'll create packet according to its setting. We are able to complete messages in our SW, but we have to explain it to our customers and to explain why others converters don't do it.
Would it be such a big problem to modify it in your FW?

[TomNB]

Are you sure your settings are correct? You mention 100ms as the max time to wait. At 19,200 baud each byte from serial takes about 521us, so 512bytes would be 267ms.

[Foxtron]

Thanks for the answer, bud it didn't satisfy me.
First - as I wrote in my first post I have serial messages of max length 50 char. It takes 50x512us=25,6ms. I've set number of accumulated char. 512, for sure to flush whole message in one packet.
Second - I tried to find what exactly means the time "to wait for accumulated characters". Is it time since first character of a serial massage? As I see from your answer - yes. Or is it time since last received charachter? According to your manual ("number of miliseconds to wait since last character before sending a packet") - yes? What's right? (I'd prefer the second possibility).
Third - the setting the same time (100ms) in converter of another producer works properly.
Nevertheless is your answer hopefull. It look's like: we think it should work. I think so.

[TomNB]

I watched a test this morning of sending 50 bytes from serial to network with same packetization settings, and all 50 bytes of data were in a single packet. I am not certain why you are seeing different results. The release number was 1.67

[TomNB]

To reduce the number of variables I would try the following:

1. Connect the SBL2e serial port to your computer
2. Run a serial terminal like our MTTTY
3. Create a text file with 50 characters
4. Use telnet to connect to the SBL2e. Now anything you type in telnet goes to MTTTY and vice versa.
Type some characters to verify it is set up correctly.
5. Start the wireshark capture
6. In MTTTY use the Transfer->Send Text File option to send your text file

[Foxtron]

I'm going to send you a picture of serial massage from osciloscope, a data from serial terminal and a data from wireshark tomorrow. You'll see. It happens irregularly (ones per 15s) and it seems to be dependent on quantity of other TCP communication (it's only theory).
We use the release number 1.65. Could the older release cause the splitting of packets?

[pbreed]

If the TCP system needs to send a packet for other reasons (say to ack the other side)
it will send whatever data it has available when it sends that packet.

Even if the netburner only sent TCP packets with your whole message in it, there is no guarentee that the routers and smart switches in the path would honor that.
in TCP packets really have no meaning, the stream can be broken up or sent in one all is exactly the same...

If you are trying to packetize TCP then it needs to be at a higher level then the actual network packets.