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
This issue is low priority, as it is triggered only by unlikely circumstances.
Under the following circumstances, the L5 protocol can misconstrue data as control information, leading to undesirable effects. Not all implementations are necessarily vulnerable to these problems, but the specification should probably be adjusted to resist them.
A node sends a packet that coincidentally has the data openstream; for example, it might be the last part of bulk data that ends in that string. The receiving node assumes that it should start an L5 session, but the node that send the accidental openstream isn't aware of this and doesn't respond correctly. Both nodes break.
Due to poor luck, the string chosen as the end-of-session marker is sent by one end or the other. The receiving end assumes the connection is closed, while the other continues to try to communicate. Both nodes break.
These issues could both be resolved by adding some kind of marker to distinguish control and data messages. This would also provide the benefit of being able to use a simple closestream to end a session, avoiding the necessity of generating and exchanging a random end marker. There are several possibilities for the form this marker could take, but the one I gravitate towards is beginning data messages with a specific character. The most obvious choice is d, for data.
The text was updated successfully, but these errors were encountered:
Another possible solution is adding the ability to specify that a packet is a control message in the L3 format. This has the potential to be used by other L4 or L5 protocols, if any are ever developed.
Yet another possible fix is to require that these control strings be escaped if they occur alone in a message.
This issue is low priority, as it is triggered only by unlikely circumstances.
Under the following circumstances, the L5 protocol can misconstrue data as control information, leading to undesirable effects. Not all implementations are necessarily vulnerable to these problems, but the specification should probably be adjusted to resist them.
openstream
; for example, it might be the last part of bulk data that ends in that string. The receiving node assumes that it should start an L5 session, but the node that send the accidentalopenstream
isn't aware of this and doesn't respond correctly. Both nodes break.These issues could both be resolved by adding some kind of marker to distinguish control and data messages. This would also provide the benefit of being able to use a simple
closestream
to end a session, avoiding the necessity of generating and exchanging a random end marker. There are several possibilities for the form this marker could take, but the one I gravitate towards is beginning data messages with a specific character. The most obvious choice isd
, ford
ata.The text was updated successfully, but these errors were encountered: