Le 10/21/13 11:42 AM, Dhruv Chopra a écrit : > I'm looking for some advice on how to best handle one of our scenarios > > 1. Clients send UDP requests to the server > 2. The server responds back to the requests > 3. The server also needs to send out of band messages (notifications) to > the clients on UDP > > > For handling 1 and 2, what I do currently is quite straight forward in that > when I get messageReceived event, I simply write back the response on the > same IoSession (Datagram). > > For case 3 - currently what I do is create a new Datagram socket and packet > and send message to the client directly i.e. not using IoSession or any > other Mina construct. (I maintain the client UDP port and address). This > works fine but the problem is that *source port* of the datagram sent this > time (#3) is obviously different from the one that sends the response (#2). There is no way to send a OOB packet using NIO. The |sendUrgentData() method is not available in NIO, so obviously your soluton is the only available one.| > > This causes issues on the client side which expects the same address/port > pair for both #2 and #3. > > One solution that I've tried for this is to hold on to a reference of the > IoSession (datagram) that I get in step 1 and 2. Then when I need to issue > a notification - I write on this cached reference. This works well in my > test and the source port of the UDP message received on the client is the > same (since underneath its all going on the same single socket now). > > I would like to know if this approach could have any performance issues > when I have cached thousands of such IoSession references and each needs to > send say 10 messages a second. Since from the OS perspective its all going > in and out through one socket this way - could this be a problem? Well, as it's UDP, there is no guarantee whatsoever that your messages are going to be received anyway, so it's really a best effort solution anyway.
Here, I would say you have to benchmark your solution... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
