First of all, sorry for so many mistakes. I was really trying to get
my ideas on paper(?), not code the new routines.
Per Guy Harris -
>
> I might be inclined to pass the flags as a separate argument from the
> port-number type, however. You might store the flags and port type in
> one field internally to the conversation code, but still pass them as
> separate arguments.
>
I was trying to keep from breaking the current code. So I opted for
adding an extension to the ptype value not adding another field. I'm
flexible on this issue, we'll just have to patch the dozen or so dissectors
that use conversations if we add another field to the call.
> Note that, in some cases, the lack of a destination address and/or port
> may be temporary; consider, for example, TFTP, where the first packet of
> a TFTP conversation is from <client address, client port> and to <server
> address, TFTP port>, the reply is from <server address, some other
> server port> to <client address, client port>, and all subsequent
> traffic is between <client address, client port> and <server address,
> other server port>.
Are you suggestion that we add functionality to set the destination address
or port after the conversation is created? An excellent idea. For example
-
void conversation_set_dst_addr( conversation_t *conv, address *dst);
void conversation_set_dst_port( conversation_t *conv, port_type ptype);
-or-
void conversation_set_addr( conversation_t *conv, address *dst);
void conversation_set_port( conversation_t *conv, port_type ptype);
Jeff Foster
jfoste@xxxxxxxxxxxx