I've got all my UDP troubles sorted out. After my SumUp adventure (and solving my weird log problem -- curse you \lib\ext !).
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). 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. 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. 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? -- Jeroen Brattinga
