Receive packet packet data from a TCP socket?

Question

I have a tcp socket on which I receive a video stream. I want to receive data as a packet by packet from a socket, so that I can remove the packet header and save only the stream data. How can i do this?

Any help would be appreciated.

Answer 1

You can not. TCP does not work with packets / messages, etc. TCP works with bytes. You get a stream of bytes. The problem is that there is no guarantee that the number of bytes you will receive each time you read from the socket. The usual way to handle this:

• If you want to send a “package,” include the length as the first thing
• When reading material from a socket, be sure to read at least that length

Your message may be:

 |Message Length:4bytes|Additional header Information:whatever1|Message Data:whatever2| 

What you need to do is read 4 bytes, and then read as much as 4 bytes tell you. Then you can delete the header and get the data.

Answer 2

TCP is a streaming protocol. You get bytes without message boundaries. The solution is to buffer all your readings and extract / process full video packets from the buffer.

Algorithm:

• Initialize an empty buffer.
• Examine the buffer for a complete package.
• If found, delete the complete packet from the beginning of the buffer and process it.
• If not found, add the data from recv() to the buffer and go to # 2.

What contains the “full packet” must be determined by the video streaming protocol.

Answer 3

TCP is a stream protocol, and it does not guarantee that when you call the socket read function, you will receive one complete packet. UDP or SCTP are packet-oriented protocols and guarantee this. For TCP, you can receive part of a packet or several packets at the same time. You need to create your own application protocol on top of TCP messages and manual fragmentation / defragmentation.

Answer 4

As already mentioned, TCP is a streaming protocol. This means that from the point of view of the API there is no concept of a “package”. As a user, all you can expect is a stream of data.

Internally, TCP splits the stream into segments that can be placed in IP packets. These packets will be sent along with the control data over IP to the remote end. The remote end will receive these IP packets. It can discard specific IP packets (in the case of duplicates), reorder packets, or hold data until earlier packets arrive. All this is internal to TCP, which means that the concept of a "TCP packet" does not make sense.

You might be able to use raw sockets to receive raw IP packets, but that would mean that you would have to override most of the TCP stack (for example, send an ACK and adjust the window size) to get the remote end to work properly. You do not want to do this.

UDP, on the other hand, is a datagram protocol. This means that the user receives information about how data is transmitted over the network. If the concept of packets or datagrams is important to you, you will need to create your own protocol on top of UDP.

Answer 5

Are you sure about that? In my opinion, this “preprocessing” will result in additional system overhead. And, of course, this is handled by a lower level (see OSI Model Overview), so it is not easy to change it. Note that most existing streaming protocols are already optimized for better performance.