1

Is there a way to guide the OS (WIN7) to send big data (3MB and such), in 1 packet with C++ sockets?

I mean sending data with "send" function without seperate the data to a lot of packets:

iResult = send( ConnectSocket, &vect[0], vect.size(), 0 ); // Sending The File

(Im trying to send png file sized 3MB through sockets). Thanks.

user2367115
  • 53
  • 3
  • 10
  • Why do you want to do this? – pilcrow May 10 '13 at 13:43
  • I'm not sure if you're confused here. Do you really mean *one* packet, or do you want to know how to send 3MB through a socket (over TCP?)? – Joe May 10 '13 at 13:44
  • @pilcrow because I have problem with recognizing the end of the image data (because I want to send another data after this data) while I'm receiveing in my python server, so I think I found a solution and the solution is to seperate the data be sending each data in different packet. – user2367115 May 10 '13 at 13:49
  • @joe I really mean one packet. I successfuly sent 3MB with sockets but seperated to different packets. – user2367115 May 10 '13 at 13:49
  • 3
    The whole notion of how IP works is that it is packetised. TCP nicely hides this from you, but every hop on a route will have its own limit to the size of packet it can take - ALL will be relatively small. Or do you have complete control of the infrastructure between the two sockets? – Joe May 10 '13 at 13:52
  • 1
    If you want to send two or more PNG file contents down the same connection then maybe you should prefix each stream of data with some kind of control information, such as the size of the PNG file. The other end will then know how many bytes to read till the end of the file contents. – jarmod May 10 '13 at 13:53

4 Answers4

4

Given that the length field of an IP packet is 2 bytes, no. Your stream will be broken into packets of at most 65k. But since TCP is a stream protocol it is up to the implementation how the packets are formatted and sent. You are only guaranteed to get the data you sent in the order you sent it.

If you want to know where the end of your sent data is, consider sending the data size first then reading that amount of data.

unsigned int len = vect.size();
iResult = send( ConnectSocket, &len, sizeof(len), 0 ); // Sending The Length
iResult = send( ConnectSocket, &vect[0], vect.size(), 0 ); // Sending The File

Then on the receiving side:

unsigned int len;
iResult = recv(socket, &len, sizeof(len), 0);
// now you know how much data to read to get your png

Also note, you should check how much is sent during each call to send since it does not have to send the entire buffer in a single call. Same with recv. You may have to call recv multiple times to read the entire sent data.

Dave Rager
  • 8,002
  • 3
  • 33
  • 52
1

Probably not. The buffers used within winsock have their limits. And at a lower (network) level TCP/IP has its limits on packet size.

ScottMcP-MVP
  • 10,337
  • 2
  • 15
  • 15
1

TCP is a stream transport, not a packet transport, and you will never get a guaranteed packet size. Also, there are size limits implemented in software and hardware, way lower than your desired size.

If you want to send packets instead of a stream, you can use UDP, with its own shortcomings. And a packet that large is entirely impossible. See What is the largest Safe UDP Packet Size on the Internet

Community
  • 1
  • 1
ypnos
  • 50,202
  • 14
  • 95
  • 141
  • Ok. well, I tried several solutions like recognize the end of the data by EOF char. but it doesnt work. do you have any other solution for my problem? – user2367115 May 10 '13 at 13:58
  • Well obviously you transmit the amount if bytes that follow first, then the payload. And then on the receiving end you sit and wait until you collected the amount of data that was promised. TCP is very reliable in getting you all the data you sent, eventually, in the right order. – ypnos May 10 '13 at 14:14
1

This clearly sounds like you need a bit of "protocol". You need a way to tell the other end what to expect. For example, you could send the first four bytes (or 8 bytes) of the packet as a "length" of the entire transmission, followed by, for example, 3MB of data. The reciving side receives a packet at "start", which contains the length of the data, and then proceeds to fetch all the data needed for that transmission. Once all the data has been received, start over by receiving a length, and then loop until all data has been received for that one.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227