• 0

Sending large message over TCP


Question

Hello, I have a little client-server application using tcp sockets. On both sides I use a buffer size of 4096 and I run all my tests with the client and server on the same machine, using address 127.0.0.1. Everything is going well except that now I suddenly need to send much larger messages. A message could now easily be 12MB in size. Now, what happens is that the transmission is incomplete : on the receiving end, I only get a chunk of the message instead of the whole thing.

I thought about simply increasing the buffer sizes on both ends to something larger than my maximum message size, but I'm not sure that's a reliable method, even if it works, and I'm not sure it'll work (if it's supported by TCP, if I won't run out of memory, etc.).

I also thought about splitting the message and actually my sending code automatically does that already, it will keep sending until all the data has been sent. However, on the receiving end, how do I know where a message ends, do I need to implement a protocol for that? I thought TCP already took care of that.

Anyway I'm a bit lost there, thanks for any tips.

Link to comment
https://www.neowin.net/forum/topic/809920-sending-large-message-over-tcp/
Share on other sites

9 answers to this question

Recommended Posts

  • 0

The main way to doing this (which you may have realized) is to send header data with each packet sent. About 5 years back when I got into remote desktop applications (using VB6 and winsock) I'd send something like 0|DATA. Each time something was sent, an integer was prefixed with the character | as the splitter. Alternatively, if you aren't sure what characters may be sent through, you can instead use char(0) (invisible char if displayed but detectable w/ programming). I'd have constants/enumerator defining exactly what each pre-fixed integer means (something like const FIRST_DOWNLOAD_PACKET = 0; const NEXT_DOWNLOAD_PACKET = 1; const LAST_DOWNLOAD_PACKET = 2;) and so forth. Whenever the client application would receive a packet, I'd split the packet into 2 - header info and data. Header information told me what to do with the information while the data contained the actual information.

You could create a class to handle something like this too (something like a packet class) for re-using in other apps using sockets.

  • 0
  dlegend said:
The main way to doing this (which you may have realized) is to send header data with each packet sent. About 5 years back when I got into remote desktop applications (using VB6 and winsock) I'd send something like 0|DATA. Each time something was sent, an integer was prefixed with the character | as the splitter. Alternatively, if you aren't sure what characters may be sent through, you can instead use char(0) (invisible char if displayed but detectable w/ programming). I'd have constants/enumerator defining exactly what each pre-fixed integer means (something like const FIRST_DOWNLOAD_PACKET = 0; const NEXT_DOWNLOAD_PACKET = 1; const LAST_DOWNLOAD_PACKET = 2;) and so forth. Whenever the client application would receive a packet, I'd split the packet into 2 - header info and data. Header information told me what to do with the information while the data contained the actual information.

You could create a class to handle something like this too (something like a packet class) for re-using in other apps using sockets.

Yes, that's pretty much what I did, although more simple. My problem was basically how to send variable length messages; the receiving end has no idea where a message begins and where it ends. Sending fixed-sized messages is fine though, I can just buffer the input and split every [LENGTH] bytes. (where LENGTH is, of course, a constant)

So how I solved it is that I each time I send a message, I prefix it with a fixed-size header containing the length of the message. Another way I could have done it is to begin and end each message with a special character, but I was worried that could too easily break.

And yup this is all encapsulated in a nice, single-purpose, reusable class. :p

  • 0

the tcp protocol will ensure the data arrives in the correct order if you just break it up into chunks and send them off one after the other

the most stable/reliable method i've come across is where you send a packet and don't send anymore until the client responds with some form of acknowledgement

server sends 4KB

client responses "ok"

server sends 4KB

client responses "ok"

~ repeat

problem with that is the speed is now completely dependant on latency and you can't take advantage of burst techniques however if you're sending to a low latency network you shouldn't have many issues

always good to have various approaches for various network types to get the most out of them :D

  • 0
  DDStriker said:
the tcp protocol will ensure the data arrives in the correct order if you just break it up into chunks and send them off one after the other

the most stable/reliable method i've come across is where you send a packet and don't send anymore until the client responds with some form of acknowledgement

server sends 4KB

client responses "ok"

server sends 4KB

client responses "ok"

~ repeat

TCP handles acknowledgment and throttling for you automatically. If you're wanting to send data to a remote endpoint as fast as possible, you might as well send it in chunks of 4096 bytes and let TCP handle those. If throttling occurs, eventually send() will not return for awhile on the local side until the congestion has been alleviated.

  • 0

Since you're already splitting your messages at this point, you may want to reduce their size. 4096 byte packets are definitely going to be fragmented (unless this is a specialized closed network of some sort, this would even fragment on the old token ring), and that could result in latency due to retransmission. 1456 would be a typical size that would not fragment on most contemporary ethernet networks (1500 MTU, 20 byte IP header, 24 byte TCP header).

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Generally, Earth never initiated that animals lay straight
    • Several UI improvements masquerading as a major update. I'm truly hating this trend.
    • OpenAI to use Google Cloud despite rivalry, diversifying beyond Microsoft by Paul Hill To help it meet its massive computing demands for training and deploying AI models, OpenAI is looking into a surprising partnership with Google Cloud to use its services. It was widely seen that OpenAI was Google’s biggest threat, but this deal puts an end to the idea that the pair are purely competing. The two companies haven’t made any public announcement about the deal but a source speaking to Reuters claimed that talks had been ongoing for a few months before a deal was finalized in May. Notably, such a deal would see OpenAI expand its compute sources beyond Microsoft Azure. Microsoft had arrangements in place with OpenAI since 2019 that gave it the exclusive right to build new computing infrastructure for the startup. This limitation was loosened earlier this year with the announcement of Project Stargate. OpenAI is now allowed to look elsewhere for compute if Microsoft is unable to meet the demand. A win for Google Cloud, a challenge for Google's AI strategy The deal will see Google Cloud supply computing capacity for OpenAI’s AI model training and inference. This is a big win for Google’s Cloud unit because OpenAI is a massive name in AI and it lends credence to Google’s cloud offering. It also justifies Google Cloud’s expansion of its Tensor Processing Units (TPUs) for external use. On the back of the news, Alphabet’s stock price rose 2.1%, while Microsoft’s sank 0.6%, showing investors think it’s a good move for Google too. While many end users don’t interact with Google Cloud the same way they do with something like Android or Chrome, Cloud is actually a huge part of Google’s business. In 2024, it comprised $43 billion (12%) of Alphabet’s total revenue. With OpenAI as a customer, this figure could rise even more given the massive amounts of compute OpenAI needs. By leveraging Google’s services, it will also give OpenAI access to the search giant’s Tensor Processing Units (TPUs). Unlike GPUs, these chips are specifically designed to handle the kinds of calculations that are most common in AI and machine learning, leading to greater efficiency. Google’s expansion of these chips to external customers has already helped it attract business from Anthropic and Safe Superintelligence. While Google will happily take OpenAI’s money, it needs to tread carefully giving compute power to a rival, which will only make OpenAI more of a threat to Google’s search business. Specifically, it’ll need to manage how resources are allocated between Google’s own AI projects and its cloud customers. Another issue is that Google has been struggling to keep up with the overall demand for cloud computing, even with its own TPUs, according to its Chief Financial Officer in April. By giving access to OpenAI, it means even more pressure. Hopefully, this will be short lived as companies compete to build out capacity to attract customers. OpenAI's push for compute independence Back in 2019 when Microsoft became OpenAI’s exclusive cloud partner in exchange for $1 billion, the AI landscape was much different. End users wouldn’t have access to ChatGPT for another 3 years and the rate of development of new models was less ferocious than it is today. As OpenAI’s compute needs evolve, its relationship with Microsoft has had to evolve too, including this deal with Google and the Stargate infrastructure program. Reuters said that OpenAI’s annualized run rate (the amount they’ll earn in one year at its current pace) had surged to $10 billion, which highlights its explosive growth and need for more resources than Microsoft alone can offer. To make itself more independent, OpenAI has also signed deals worth billions of dollars with CoreWeave, another cloud compute provider, and it is nearing the finalization of the design of its first in-house chip, which could reduce its dependency on external hardware providers altogether. Source: Reuters
    • I don't think that means what you think it means
    • The Google Home app gets video forwarding support and many more features by Aman Kumar Along with releasing the Android 16 update for supported Pixel devices, Google has also showcased a number of features coming to its Home app. First up is PiP, also known as picture-in-picture mode, which will be available for Nest Cams on any Google TV device you own. It’ll be similar to YouTube’s PiP, with which you must be familiar with. A small window will appear in a corner of the TV screen, allowing you to view your Nest Cams without interrupting your viewing experience. The feature is currently in public preview, and you can enroll to try it out before its public release. Another YouTube feature that Google is adding to its Home app is the ability to jump 10 seconds forward or backward in recorded videos. This feature ensures that you don't have to go through the entire footage to locate the moment you’re looking for. Google mentioned in its blog post that it is adding more controls to the Google Home web app. Currently, the web app offers limited functionality, such as setting automations and viewing cameras, but soon you’ll be able to manage more things through it, such as adjusting lighting, controlling temperature, and locking or unlocking the door. Google’s AI model, Gemini, is also getting more controls in the Home app. You can use natural language in the Gemini app to search for specific footage in the camera history. Furthermore, the fallback assistant experience that broadcast commands use is also being updated. You’ll now be able to use your voice to broadcast messages through the connected speakers in your home. The Google blog post also mentions that you are no longer required to use the standalone Nest app to receive smoke and other critical alerts. You can now view the Nest Protect smoke and carbon monoxide (CO) status directly in the Home app. You’ll also be able to run safety checkups and hush alarms through the Home app. In addition to all these features, Google is also making the automation creation process much quicker, will allow you to add more tiles to the Home app Favorites section, and will let you create different Favorites for any other device you use, such as your smartwatch. The Home app will now also support third-party Matter locks. Similar to the Nest x Yale lock, you’ll be able to control various settings of these third-party locks, like managing household access, creating guest profiles, and more.
  • Recent Achievements

    • Week One Done
      Falisha Manpower earned a badge
      Week One Done
    • One Month Later
      elsa777 earned a badge
      One Month Later
    • Week One Done
      elsa777 earned a badge
      Week One Done
    • First Post
      K Dorman earned a badge
      First Post
    • Reacting Well
      rshit earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      544
    2. 2
      ATLien_0
      272
    3. 3
      +FloatingFatMan
      207
    4. 4
      +Edouard
      201
    5. 5
      snowy owl
      139
  • Tell a friend

    Love Neowin? Tell a friend!