Ford, Alan schrieb:
Hi Christian, Henning,
I have been undertaking some informal testing of your GIST implementation with ours, and noticed one notable incompatibility when the Q/R DMode negotiation occurs, regarding port numbers:
We send: Q from port 3xxxx -> port 4 on the responder And send a response: R from port 4 on the responder to port 3xxxx on the query node
You send: Q from port 3xxxx -> port 4 on the responder (as do we) But, you send a response: R from port 3xxxx on the responder to port 4 on the query node
We pick up everything going to port 4 so if you are the responder and we are the query, that works. But with you as the query node and us as the responder, our response is not picked up because it goes to port 3xxxx. At least, I think that explains the behaviour I am seeing - if I force it to port 4, it works.
In the spec, section 5.3.2 says "the source UDP port...receives UDP messages in reply". And section 5.3.1 says "UDP port numbering must be...the same for messages in the same direction and swapped otherwise".
Discussions with the Rob Hancock here suggests that our implementation was the intended way.
You are the first external to notice that bug, but I am already aware of it (for one month) since I made another review of the GIST draft version 10. I just missed that section in the draft when implementing and (really funny) at the interop at Paris no one complained and it seems all other implementations (including the roke one) did not have problems with that.
I guess the most trivial fix would be to send our Query from port 4, right? I will try to fix this bug as soon as possible. Thank you very much for pointing this out.
Regards, Christian Dickmann
Hi,
We pick up everything going to port 4 so if you are the responder and we are the query, that works. But with you as the query node and us as the responder, our response is not picked up because it goes to port 3xxxx. At least, I think that explains the behaviour I am seeing - if I force it to port 4, it works.
In the spec, section 5.3.2 says "the source UDP port...receives UDP messages in reply". And section 5.3.1 says "UDP port numbering must be...the same for messages in the same direction and swapped otherwise".
I guess the most trivial fix would be to send our Query from port 4, right? I will try to fix this bug as soon as possible. Thank you very much for pointing this out.
I committed a change to our development tree, which forces every outgoing packet to be send from port 4. This should "fix" the problem you had, namely, that you send the response to the source port we used in the query and this packet getting dropped. Of course, our implementation is still wrong, as it does not reply to the source port of the query when we switch roles. But as you wrote, you always listen on port 4, so this works for now.
To really fix this issue, I will need a little more time, as this requires some changes to our sending logic. Can you please ask Robert if it is safe to set the source port of the Query to the well known GIST port (aka 4 at the moment) or to another fixed port assigned by our implementation. What is a good policy to set the source port? (I am not sure, why Robert designed the port stuff this way)
BTW: What happened to Chris Lang (I hope this was his name). I think he was the one who worked on the roke implementation when we met in Paris, is this right?
Christian Dickmann
nsis_imp@informatik.uni-goettingen.de
-
Christian Dickmann