Re: Packet format in ENRP
Michael Tuexen <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Dear all, just one note: the R flag in the PEER_PRESENCE message means 'reply required' and in the PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE it means 'reject'. So it is not just 'one bit'. On Jul 8, 2004, at 12:12 AM, Johnson Walter-CWJ002 wrote: > I agree with all the changes but would like to suggest another. Much > like Michael's suggestion in section 3.3 to align the R bit in > PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE. > How about the following for the 8 bit flag field. Define bit 15 to be > the R flag bit, bit 14 to be the M flag bit, and bit 13 to be W flag > bit as shown below the pertinent ENRP protocol messages. This would > allow a single mask at least until the time that more than 8 flags > were required. > > PEER_PRESENCE 0000000R > PEER_NAME_TABLE 00000W00 > PEER_NAME_TABLE_RESPONSE 000000MR (Change as suggested by Michael) > PEER_LIST_RESPONSE 0000000R > > This would also work for the ASAP protocol messages as currently > defined. > > REGISTRATION_RESPONSE 0000000R > > Walter > > Qiaobing Xie <> wrote: >> Michael, >> >> Michael Tuexen wrote: >> >>> Dear all, >>> >>> while writing the ethereal dissector for ENRP I found some things I >>> would like to change: >>> >>> Section 3.1 >>> >>> The length field is shown as 'Message Length = 0xC' which >>> is not correct because there can be some parameters. >> >> good catch. >> >>> >>> Section 3.3 >>> >>> Could we exchange the R and M bit? This would align the >>> R bit position with the reject bit in a PEER_LIST_RESONSE message. >> >> I agree. Better alignment is always good :-) >> >>> >>> Section 3.4 >>> >>> To have a similar layout of the packets i would suggest to change it >>> to: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>> 0 1 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> Sender Server's ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> Receiver Server's ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> Update Action | (reserved) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : >>> Pool handle : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : >>> Pool Element : >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Makes sense to me. I agree. >> >> regards, >> -Qiaobing >> >>> >>> Best regards >>> Michael >>> >>> PS.: ethereal version 0.10.5 will support both ASAP and ENRP... >>> >>> >>> _______________________________________________ >>> rserpool mailing list >>> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool >>> >> >> >> _______________________________________________ >> rserpool mailing list >> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool >