In gmane.network.ethereal.cvs (<20040104204244.D6A1C46174@xxxxxxxxxxxxxxxxx>), you (guy@xxxxxxxxxxxx) wrote:
> guy 2004/01/04 14:42:44 CST
>
> Modified files:
> . packet-x11.c
> Log:
> Move a comment to the appropriate location, and put in another comment
> about problems with handling replies.
>
> Revision Changes Path
> 1.51 +26 -6 ethereal/packet-x11.c
...
Don't remember how the other things you bring up worked anymore,
so I'll just comment on what I do vaguely still remember.
* We might, instead, want to assume that a reply is a reply to
* the most recent not-already-replied-to request in the same
* connection. That also might mismatch replies to requests if
* packets are lost, but there's nothing you can do to fix that.
That consistently didn't work, though I unfortunately don't remember
what the problem was, except it having something to do with, when
the client sent request A and B, we in tethereal saw the reply B'
and A', I think.
* XXX - if "opcode" is 0, we shouldn't say "Unknown opcode",
* we should say that we don't have the request for the reply.
That could be the case, but in the cases I saw, it really is "Unknown
opcode", i.e. it's a server specific extension. Since we don't
know what the request opcode means, we don't know when it is expecting
a reply either, so we don't know to save state for that. Perhaps
this has something to do with the problem mentioned above.
Regards,
--
_ //
\X/ -- Michael Shuldman <michaels@xxxxxxx>
