|
> > Why should the ID be unique regardless of packet code when run > > over reliable transport, but not UDP? This suggests that the ID is > > being processed differently for unreliable vs. reliable transport, which > > seems odd. > > With UDP, there is no "connection" from client to server. So any > Status-Server checks are sent from any client port. This removes much > of the problem of reserving one ID: the client just opens another source > port. > > If it uses the same source port for Status-Server as for > Access-Request, then it would need to ensure that the ID allocated to > Status-Server is unused by any Access-Request. The problem is not so much with the Status-Server/Access-Request ID conflict, as with the potential conflict of Access-Accept IDs, correct? > With TCP, there is a connection between client and server. The > watchdog timer algorithm in RFC 3539 is defined per *connection*. So an > ID has to be reserved, because the client can't open a new connection to > test if an existing connection is still alive. Ah. I understand now. Let's talk about the implications of this on a separate thread. Some of the above logic might be worth putting into the document. |