Implementing this option as variable length is not RFC compliant. If you
would like to be forwarded the discussion about fixed vs. variable length --
the option was originally variable length -- please let me know. Until then
it is best to follow the RFC, assuming that you are trying to implement DCCP
rather than something else.
Eddie
Gerrit Renker wrote:
Quoting Wei Yongjun:
Now non-negotiable feature does not has a fix size, it's length is
decide by the value of the non-negotiable feature. For example, the
client send Sequence Window Feature as the following: 0x23 0x04 0x03
0x64, the Sequence Window Feature has the length of 1-byte only.
But RFC4340 said:
7.5.2. Sequence Window Feature
Sequence Window has feature number 3 and is non-negotiable. It takes
48-bit (6-byte) integer values, like DCCP sequence numbers. Change and
Confirm options for Sequence Window are therefore 9 bytes long.
Is this correct? Or there are some RFCs said the non-negotiable feature
has variable length?
You are correct - the RFC states fixed lenghts, even if values can be
communicated in much smaller options.
The implementation does not implement the fixed lengths suggested by the
RFC, since this does not make sense. The implementation will always chose
the smallest-possible container length.
I believe that this is the preferrable approach. In particular since
DCCP is a protocol which has a special header flag (`X') to allow saving
3 bytes. Why use 6 bytes when the value fits comfortably in a single
byte?
Moreover, a lot of problems are generated by all these copious option
lengths - unless using very small payloads, it is easily possible to
exceed the maximum packet size.
Thus, although the RFC says otherwise, I think that using the smallest
option size for a given value is the right thing to do.
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
