Partially Recived Packets and DataArrival

[Adron]

When analyzing tcp streams in Ethereal, you should use the Follow TCP Stream feature on the Tools menu.

Don't look at the individual packets as they are displayed in the bottom pane unless you're interested in debugging incomplete packet sends causing additional RTT delays, TCP disconnections, dropped packets, or something like that.

Like Skywing says, TCP is stream based, and the packets don't matter to TCP, only the stream.

[tA-Kane]

What Skywing and Adron are trying to say, without being obvious is yes, it is indeed possible to receive a partial BNCS packet. But you see, because TCP is a reliable stream, you will receive the rest of the packet (or perhaps even just another part), before receiving the next packet.

Now for a solution to your problem, think of a solution to this logic quiz:

You are expecting 3 BNCS packets.
You receive part of the first packet.
Some time later, you receive another part.
Even later, you receive both the end of the first packet, and the beginning of the second packet, but the number of bytes you receive of the second packet is only two bytes; that is insufficient to know the length of the BNCS packet.
After some time, you receive the end of the second packet.
Lastly, you receive the third packet in whole.


This logic problem is possible both with and without a proxy connection, and it is also possible to parse all three packets in their entirety.

[Adron]

Yes, think of reading from a tcp socket as of reading from a file or anything similar - you can read one byte at a time and there are no packets.

[iago]

The solution to Kane's problem:
Think of each packet as 2 seperate packets.  A header, which is 4 bytes, and the rest, whose length is specified by the header.  


Now this got me to thinking: do we really need packetbuffers?  I propose that somebody write a bot which,instead of insertDword, insertNTString, etc, just sends the data as the packet is built.  

So:
sendByte(0xFF)
sendByte(0x0E)
sendWord(0x09)
sendNTString("Moo!");

[dxoigmn]

The solution to Kane's problem:
Think of each packet as 2 seperate packets.  A header, which is 4 bytes, and the rest, whose length is specified by the header.  


Now this got me to thinking: do we really need packetbuffers?  I propose that somebody write a bot which,instead of insertDword, insertNTString, etc, just sends the data as the packet is built.  

So:
sendByte(0xFF)
sendByte(0x0E)
sendWord(0x09)
sendNTString("Moo!");

You can't always do this becuase the size of the packet may vary depending upon content.

[K]

"dxoigmn**subterranean homesick alien/."

Mind explaining?

dxoigmn**subterranean homesick alien

[Kp]

You can't always do this becuase the size of the packet may vary depending upon content.

Actually, you can send it piece by piece (though this would be much less efficient for everybody involved).  You just wouldn't necessarily be able to hardcode the packet length, but it's not that much trouble to compute the length, then send it, then send each of the pieces.

[Arta]

Yes, it would be a great deal less efficient. For functions that operate on variable amounts of data, like send(), it makes much more sense to call them once, with lots of data, than lots of times with little data. The reason being that calling a function incurs some overhead in terms of CPU time. If you call such a function once with 1024 bytes of data, you incur that overhead once. If you call it 4 times with 256 bytes of data, you incur 4 times as much overhead.

[Adron]

The biggest problem is the way tcp works. I'm not sure of the exact workings, but something like this:

If you send 4 bytes, then 2 bytes, then 3 bytes, starting from zero with nothing sent before, the 4 bytes will be sent immediately. After that, the remaining 5 bytes will be held until either a timeout expires, or the first 4 bytes are acknowledged from the other end.

If you on the other hand send 9 bytes right away, they'll all be delivered immediately.

This means that it will take your complete packet another rtt to arrive at the other end if you send it piece by piece.