I am sending a payload TESTING. I am trying to calculate the checksum for the UDP header which requires UDP total length. UDP header length is 8 bytes. Can anyone explain me how to calculate the data length with the above given payload. I tried searching the internet but could not find the relevant answer.
The length of the payload is the length of the payload in bytes. So a 7 byte payload could hold the ASCII string "TESTING". You could add a NUL terminator and make it 8 bytes.
Related
According to RTSP - RTP over TCP
RTP Data
After the setup, RTP data will be sent through the TCP socket that is used for RTSP commands. The RTP data will be encapsulate in the following format
| magic number | channel number | embedded data length | data |
magic number - 1 byte value of hex 0x24
channel number - 1 byte value to denote the channel
embedded data length - 2 bytes to denote the embedded data length
data - data packet, ie RTP packet, with the total length of the embedded data length
Is that mean that the magic number (0x24) can't preset in rtp/h264 data ?
when I see 0x24 I know that it start of rtp packet?
Is that mean that the magic number (0x24) can't preset in rtp/h264 data ?
Since the actual payload is prefixed with its length it is clear where the payload starts and ends. It will not search for the magic number inside the payload, length or channel number but only at the position where the magic number should be.
when I see 0x24 I know that it start of rtp packet?
No. As explained the 0x24 can be anywhere in the data, not only where the magic number is.
By IEEE 802.3, an Ethernet frame has to carry a payload of at least 46 bytes. This is for collision detection-- collisions of smaller frames (may) go undetected.
The Q is: what if the payload to be carried is shorter? what kind of padding is used to scale the frame up to the slot size-- 64 bytes?
TIA.
To quote from Data and Computer Network Communication (emphasis mine);
If the network layer wishes to send less than 46 bytes of data the MAC protocol adds sufficient number of zero bytes (0x00, is also known as null padding characters) to satisfy the requirement.
Some buggy drivers fail to do this though as noted by Adaptec.
The 32-bit acknowledgement field, say x, on the TCP header
tells the other host that "I received all the bytes up until and including x-1,
now expecting
the bytes from x and on". In this case, the receiver may have received some
further bytes, say x+100 through x+180,
but it hasn't yet received x-th byte yet.
Is there a case that, although the receiver hasn't received
x through x+100 bytes but received the bytes say x+100 through x+180,
the receiver is acknowledging that it received x+180?
One resource I read indicates the acknowledgement of bytes received despite a gap in the earlier bytes.
However, every other source tells
"acknowledgement of x tells all bytes up until x-1 are received".
Are there any exceptional cases? I'm looking to verify this.
TIA.
This can be achieved by TCP option called SACK.
Here, client can say through a duplicate ACK that it has only up to particular packet number 2 (sequence number of packet) in order and append SACK(Selective Acknowledgement) option for the range of contiguous packets received like packets numbered 4 to 5 (sequence number). This in turn shall enable the server to retransmit only the packets(3 sequence number) that were not received by the client.
Provided below an extract from RFC 2018 : TCP Selective Acknowledgement Options
The SACK option is to be sent by a data receiver to inform the data
sender of non-contiguous blocks of data that have been received and
queued. The data receiver awaits the receipt of data (perhaps by
means of retransmissions) to fill the gaps in sequence space between
received blocks. When missing segments are received, the data
receiver acknowledges the data normally by advancing the left window
edge in the Acknowledgement Number Field of the TCP header. The SACK
option does not change the meaning of the Acknowledgement Number
field.
From the TCP RFC at https://www.rfc-editor.org/rfc/rfc793.txt:
3.3. Sequence Numbers
A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number. Since every octet is
sequenced, each of them can be acknowledged. The acknowledgment
mechanism employed is cumulative so that an acknowledgment of sequence
number X indicates that all octets up to but not including X have been
received.
That seems pretty clear to me, the sequence number stops at the first missing data.
Why does UDP have the field "UDP Length" twice in its packet? Isn't it redundant? If it is required for some kind of error checking, please provide an example.
Your observation is correct. The length field is redundant because both the IP header and the UDP header has a length field. My only guess about the reason for this redundancy is, that it happened because UDP was designed at a time, where it was not yet clear what the IP protocol suite would look like.
All legitimate UDP packets should have a length field matching exactly what could be derived from the length field in the IP header. If you don't do that, you can't know for sure, what the receiver is going to do with the packet.
UDP packets with inconsistent length fields are seen in the wild on the Internet. I guess they are probing for buffer overflows, which might happen if one length field is used to allocate memory and the other length field is used when copying data to the allocated buffer.
In the newer UDP Lite protocol, the length field has been repurposed. The length field in the UDP Lite header does not indicate how much data there is in the packet, but rather how much of it has been covered by the checksum. The length of the data in a UDP Lite packet is always computed from the length field in the IP header. This is the only difference between the UDP and UDP Lite header formats.
From RFC 768:
Length is the length in octets of this user datagram including
this header and the data. (This means the minimum value of the
length is eight.)
The pseudo header conceptually prefixed to the UDP header contains
the source address, the destination address, the protocol, and
the UDP length. This information gives protection against misrouted
datagrams. This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
The REAL answer is that this is a "pseudo header" - that is, it is used for calculating the checksum, but not actually sent. at least that is what I conclude from What is the Significance of Pseudo Header used in UDP/TCP
What is the overhead for PPP and Ethernet sending 5000 bytes?
Frame size for Point-to-Point Protocol: 8 bytes
MTU: 500 bytes
Frame size for Ethernet: 18 bytes
MTU: 1500 bytes
Both sending 5000 bytes..
I know this is just a calculation, but I am not sure how to do it. I can't find it anywhere. I would think that since a PPP frame takes 8 bytes and maximum transmission unit is 500 then it can send (500 - 8)bytes of information in one go. It sends 10 frames, resulting in 4920 bytes sent. Then sends the final (80+8)bytes with the last frame.
Similar for Ethernet. (1500 - 18)bytes with each frame. 3 frames sent means 4446 bytes sent. Sending (554+18)bytes in the last frame.
This obviously doesn't answer the "overhead" question. Anyone have any ideas?
It really depends on how you define overhead. This answer will assume overhead is the number of bytes that you need to transmit in addition to the data itself.
For Ethernet, assuming the 5000 byte payload is not encapsulated in an IP + TCP/UDP frame, you will have 18 bytes of overhead for every packet sent. That means each transmission with an MTU of 1500 will be able to hold 1482 bytes. To transmit 5000 bytes, this means 4 packets must be transmitted, which means an overhead of 72 bytes (18 * 4). Note that the overhead becomes bigger when you include things like the IP frame which contains a TCP frame.
For PPP, as you've already shown, you can send 492 bytes per frame. Eleven frames means 88 bytes of overhead (11 * 8) - again, not including any additional protocol frames within the payload.
In both these examples any protocols that build on top of these link layer protocols will contribute to overhead. For example, an Ethernet packet sent with an IPv4 frame which contains a UDP datagram will have an additional 28 bytes consumed by headers and not data (20 bytes in an IPv4 header and 8 in a UDP header, assuming no IP options). Considering the original Ethernet example, this means the amount of data per packet becomes 1454 bytes, which luckily still comes to 4 packets (the extra spills over into the smaller 4th packet), with 144 bytes of overhead.
You can read more here (I find that page a little hard to read though).