You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The framing layer has neither pattern, checksum or sequence numbers to help us tell if the sender and receiver have become mis-synchronized,
If we wanted to be strictly compliant with "end-to-end argument" we should have an integrity check, but given that we have a CRC and sums in the layers below I don't think that's really an overhead which would justify itself.
However, it would make good sense to add a pattern or sequence number to the frame header to give us a "must match field" to detect frame misalignment. (I looked at the current frames and there are no fields which lend themselves naturally to this).
If a frame header gets misaligned one byte either way, there are pretty good chances that it will still look legit enough for processing to commence.
Given that many people talk about processing frames while they are still being received, adding a more robust misalignment detection sounds like a good idea to me.
The easiest is probably a single byte sequence number which just increments from frame to frame. That number could be included in RST frames to indicate which frame caused the error.
The text was updated successfully, but these errors were encountered:
Has anybody considered frame-desynchronization ?
The framing layer has neither pattern, checksum or sequence numbers to help us tell if the sender and receiver have become mis-synchronized,
If we wanted to be strictly compliant with "end-to-end argument" we should have an integrity check, but given that we have a CRC and sums in the layers below I don't think that's really an overhead which would justify itself.
However, it would make good sense to add a pattern or sequence number to the frame header to give us a "must match field" to detect frame misalignment. (I looked at the current frames and there are no fields which lend themselves naturally to this).
If a frame header gets misaligned one byte either way, there are pretty good chances that it will still look legit enough for processing to commence.
Given that many people talk about processing frames while they are still being received, adding a more robust misalignment detection sounds like a good idea to me.
The easiest is probably a single byte sequence number which just increments from frame to frame. That number could be included in RST frames to indicate which frame caused the error.
The text was updated successfully, but these errors were encountered: