Hi Jeroen, On 10/12/06, Jeroen Brattinga <[EMAIL PROTECTED]> wrote:
I've got all my UDP troubles sorted out. After my SumUp adventure (and solving my weird log problem -- curse you \lib\ext !).
Good to hear that you found a solution, and sorry that I couldn't help you much. After examining the UDP traffic from the SumUp example and comparing it to
my own app I noticed one difference: the SumUp example has a nice cross-referenced pattern for the send/recieve packets -- sending: source port number (e.g. 1666) <--> destination port number (8080), recieving: source port number (8080) <--> destination port number (1666).
You can specify your local port number by specifying an additional InetSocketAddress in your bind() call. My own app (that communicates with a specialized piece of hardware) did not.
The recieved packets had a different source port number. It turned out to be one of those big/little endian bugs (when does the hurting stops!), but that's not the point. Up till then, all software that communicated with this hardware had no problems sending/recieving UDP packets. That includes an app that uses java.net.DatagramSocket.
This is very weird. The behavior of DatagramChannel shouldn't be different from that of DatagramSocket. :-$ In our switch to the Mina framework (and thus to java.nio.channels) no more
answers were recieved. I noticed they never got into the framework (by debugging the DatagramConnectorDelegate). Only after fixing the source port number in the responding packets everything went fine.
Hooray! Again, very happy to hear that. :D I was wondering... I thought that in the responding UDP packets only the
destination port mattered, but this seems not to be the case for java.niotraffic. Could anyone explain what is happening behind the scenes? Or am I missing something here?
I think there's an internal issue that we don't know in the NIO implementation. But I really don't think there should be such a difference in NIO and BIO. It's really awakward. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
