> One comment to the new conversation idea:
> In general it works but at least the NFS client code in ReliantUNIX 5.45
> may send a retransmission of an NFS request over a different port, because
> the RPC client structure will be freed and newly allocated after a specific
> timeout. So in this case I would expect a "duplicate transaction id"
> message for the request but since it has a different conversation
> (different client port) it will be treated as a totally new request.
>
> For the standard use (reply -> request correlation) the conversation routines
> are simple and effective but to detect a "duplicate transaction" I need some
> more freedom for my check.
Perhaps what's needed here is to
1) have the conversation routines take as arguments separate
port number types for the source and destination port;
2) have the client port number be of type PT_NONE, with a value
of 0, so that, in effect, all requests from a given machine to a
given server port on a given machine are treated as part of
the same conversation, regardless of the port whence they
came (and all replies from a given machine and a given server
port to a given machine are treated as part of that
conversation, regardless of the port to which they're
directed).