So I am seeding on BitTorrent and there appears to be two-fold communication showing up on Wireshark. From peers around the world I receive UDP packets with 20 bytes of data. In response my BitTorrent sends UDP packets with around 1438 bytes of data.
This uTorrent protocol suggested here does not seem to have anything as small as the 28 byte (20 bytes data 8 bytes header) UDP packets, likewise this link isn't helpful.
What is the formal communication mechanism or protocol at play here? Is it possible to analyze those 1438-byte packets or in more detail in order to get a snippet of the file being sent? Or the structure of the 20 bytes of data being sent from my peers?
This uTorrent protocol suggested here does not seem to have anything as small as the 28 byte (20 bytes data 8 bytes header) UDP packets
The µTP header is 20 bytes. So those most likely are ACK messages. Wireshark should support decoding those packets, at least if you captured a connection from the beginning.
Related
I want to simulate a simple client/server application streaming 2-3 4k 25 fps videos within 5G network using OMNeT++ stack. After capturing all incoming video flows with opencv and encoding with h264 codec I have roughly 20 kilobytes for each frame encoded as bytes -- uint8_t. Of course capturing for each of flow happens in a separate thread.
Now I want to send it to some clients over 5G using UDP protocol. If you look almost at every open source implementation of video streaming, the process of transmission is presented very simple:
uint_8* buffer; // encoded frame
int size; // buffer size
send(clientSocket, buffer, size, 0); // send to client
and on the client side a loop with an appropriate recv pulls. The same basically happens in every OMNeT++ simualtion.
Of course a UDP packet with around 20Kb payload will be fragmented on its way to pass good old IPv4 1500 bytes MTU at the backhaul part of a standard 5G architecture. So here comes my question: could I benefit something if I try to reduce my maximal UDP payload to, let's say, 1280 bytes to avoid IP fragmentation and to fit IPv6 minimum reassembly buffer size?
I'm afraid that if I just cluelessly send the encoded frame as in the code above, some fragmented packets may be lost and my decoder (h264 as well) on the client side can fail to decode the frame. Well however the same could happen if I send mine fragmented 1280 bytes packets... so here the question is pretty general, considering the fact that it happens in OMNeT++ simulation but with real video files: is there any advantage of controlling the packet size before sending or you just can cluelessly send any less than 64 Kb UDP datagram and just chill?
Im trying to figure out which is the maximum size of a RTP packet. I know that the minimum header size is 12 bytes, but i dont find anything about the payload.
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
I hope you understand my question :)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size?
The RTP standard does not set a maximum size so you're free to do this.
(Jumbo packets often have issues of their own with transport, but that's generally to do with the lower layer protocols playing up.)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
Yes, you could create a 1446 byte long payload and put it in a 12 byte RTP packet (1458 bytes) on a network with an MTU of 1500 bytes.
By the time you include an 8 byte UDP header + 20 byte IP header + 14 byte Ethernet header you've 42 bytes of overhead which takes you to 1500 bytes.
In practice if you're transporting this over the internet, this traffic is getting encapsulated or carried across varied transport layers, you'd probably want to keep it below 1400 bytes to be on the safe side.
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
RTP has a one-to-one mapping from one unique source to one RTP stream (Unless the streams are mixed/muxed together into one stream) so each of the MP3 sources would be put into their own RTP stream, each with it's own unique Synchronization Source Identifier (SSRC) to differentiate between each stream.
For more info on RTP there's the RFC 3550 itself, there's a great book by Colin Perkins called "RTP: Audio and Video for the Internet", I'vea fair bit on RTP on my blog and I've also created a Python library for creating RTP packets.
I am facing an issue where DTLS handshake packets are greater than 1500 bytes and I do fragment to make sure it is less than 1500 bytes. The fragmentation is as per RFC dictated. Now, when I check captured pcap, fragment and reassembled when complete packet received. However DTLS SSL_connect function when I feed fragmented packets. The question here, should I reconstruct complete packet and give it to SSL_connect function?
As I read the current(?) draft:
3.1.2. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By
contrast, UDP datagrams are often limited to less than 1500 bytes if
IP fragmentation is not desired. In order to compensate for this
limitation, each DTLS handshake message may be fragmented over several
DTLS records, each of which is intended to fit in a single IP
datagram. Each DTLS handshake message contains both a fragment offset
and a fragment length. Thus, a recipient in possession of all bytes of
a handshake message can reassemble the original unfragmented message.
I want to know, how much overhead WebRTC produces when sending data over datachannels.
I know that Websockets have 2 - 14 Bytes overhead for each frame. Does WebRTC use more Overhead? I cannot find some useful information on the web. Its clear for me, that Datachannels can not be used for now. How much overhead is used with Mediastreams?
Thanks
At the application layer, you can think of DataChannel as sending and
receiving over SCTP. In the PPID (Payload Protocol Identifier) field of the
SCTP header, Datachannel sets value 0x51 for indicating that it's sending UTF-8
data and 0x52 for binary data.
Yes, you are right. RTCDataChannel uses SCTP over DTLS and UDP. DTLS is used for
security. However, SCTP has problems traversing most NAT/Firewall setups.
Hence, to overcome that, SCTP is tunneled through UDP. So the overall overhead
to send data would be overhead of:
SCTP + DTLS + UDP + IP
and that is:
28 bytes + 20-40 bytes + 8 bytes + 20 - 40 bytes
So, the overhead would be rougly about 120 bytes. The maximum size of the SCTP
packet that a WebRTC client can send is 1280 bytes. So at max, you can send
roughly 1160 bytes of data per SCTP packet.
WebRTC uses RTP to send its media. RTP runs over UDP.
Besides the usual IP and UDP headers, there are two additional headers:
The RTP header itself starts from 12 bytes and can grow from there, depending on what gets used.
The payload header - the header that is used for each data packet of the specific codec being used. This one depends on the codec itself.
RTP is designed to have as little overhead as possible over its payload due to the basic reasoning that you want to achieve better media quality, which means dedicating as many bits as possible to the media itself.
Here's a screenshot of 2 peer.js instances (babylon.js front end) sending exactly 3 bytes every 16ms (~60 per second).
The profiler shows 30,000 bits / second:
30,000 bits / 8 bits per byte / 60 per second = 62.5 bytes, so after the 3 bytes I'm sending it's ~59.5 bytes according to the profiler.
I'm not sure if something is not counted on the incoming, because it is only profiling half that, 15k bits / second
I am using sockets in python to send files, and I am doing a packet capture while sending these files. However, I find that each packet is 1434 bytes instead of the 1500 bytes (MTU is set at 1500 bytes on my system).
I have attached some screenshots of the packet capture. I need to send the packet at 1500 bytes rather than the 1434 bytes, can some one tell me what's going on?
TCP sends whatever-sized segments it wants to send over the wire; you can't control that from the socket layer. Perhaps the remote machine is only offering a window big enough to send 1314 bytes of data (1314 + 14 bytes of Ethernet header + 20 bytes of IP header without options + 20 bytes of TCP header without options = 1368), or perhaps the congestion window isn't open wide enough to send more data.
Furthermore, you shouldn't have to control that. TCP provides a sequenced byte stream; packet boundaries are NOT significant in TCP!