OiO.lk Community platform!

Oio.lk is an excellent forum for developers, providing a wide range of resources, discussions, and support for those in the developer community. Join oio.lk today to connect with like-minded professionals, share insights, and stay updated on the latest trends and technologies in the development field.
  You need to log in or register to access the solved answers to this problem.
  • You have reached the maximum number of guest views allowed
  • Please register below to remove this limitation

Python TCP receives small segment sizes during transmission

  • Thread starter Thread starter Abszol D
  • Start date Start date
A

Abszol D

Guest
During transmission from my client to my Python server it was observed that the packet segments being received are of size 28B or there around. In turn a 364B message is taking around 41 packets between client and sever to be fully received by Python where then it’s dumped to the socket stream and read in. The latency observed by wire shark shows that it takes around 40 seconds to fully receive the message before Python begins processing it. Another thing to note that heartbeats decide and are of size 40B which in turn shows that the heartbeats show nearly no latency, < 1s based on the script I wrote that compares pcap to the json stream I record for each messages arrival time.

My reading logic looks to read the messages header which is comprised of 6 Bytes, 4 for the size and 2 for the ID. Thereafter the chunks are read in by the size of 1024B so 364B shouldn’t be a problem.

I have taken additional steps to setting TCP_NODELAY to True and the buffer receive and send to 6500B.

Has anyone ran into this issue before?

Analyzed wire shark pcap and noticed transmission segments were extremely small and caused a high frequency of them to be had, causing latencies in certain messages whereas smaller ones were fine. It appears Python waits for all the segments to be received before processing which tracks to how I linearly process the stream and messages are concurrent and don’t overlap in data received.
<p>During transmission from my client to my Python server it was observed that the packet segments being received are of size 28B or there around. In turn a 364B message is taking around 41 packets between client and sever to be fully received by Python where then it’s dumped to the socket stream and read in. The latency observed by wire shark shows that it takes around 40 seconds to fully receive the message before Python begins processing it. Another thing to note that heartbeats decide and are of size 40B which in turn shows that the heartbeats show nearly no latency, < 1s based on the script I wrote that compares pcap to the json stream I record for each messages arrival time.</p>
<p>My reading logic looks to read the messages header which is comprised of 6 Bytes, 4 for the size and 2 for the ID. Thereafter the chunks are read in by the size of 1024B so 364B shouldn’t be a problem.</p>
<p>I have taken additional steps to setting TCP_NODELAY to True and the buffer receive and send to 6500B.</p>
<p>Has anyone ran into this issue before?</p>
<p>Analyzed wire shark pcap and noticed transmission segments were extremely small and caused a high frequency of them to be had, causing latencies in certain messages whereas smaller ones were fine. It appears Python waits for all the segments to be received before processing which tracks to how I linearly process the stream and messages are concurrent and don’t overlap in data received.</p>
 

Latest posts

Top