Hi,
Radim Kolar SF.NET wrote:
>> If I understand correctly your question, the SelectionKey is associated
>> with the connection, not the packet. Hence all packets from the same
>> connection use the same SelectionKey. It that what you ask?
> I think Grizzly needs some tuning for better support for writing UDP
> servers. His UDP support seems to be limited to writing udp client apps.
>
> Main problem is:
> all UDP packets arriving into same server ip:server port combo are sharing same SelectionKey.
> this cause some problems:
Can you explain how to handle that with NIO? Grizzly uses SelectionKey,
but the creation is made by the NIO layer of the JDK. If I understand
the issue properly, you would like to have one packet per SelectionKey?
> * at lot of places in code filters/other components are canceling SelectionKeys on io errors (such as UDP output buffer full). If they cancel SelectionKey, server socket is closed and nobody other
> can use server until server is restarted.
Hum, that would be a bug if that's the case. When the SelectionKey is
cancelled, it means the connection is either closed by the client of
something unexpected happens. Do you have a test case I can use to
reproduce the problem?
> * DefaultSelectionKeyHandler closes server socket after 30 secs of
> inactivity
Yes that's a design decision we took. You can disable the feature by doing:
> DefaultSelectionKeyHandler keyHandler =
> new DefaultSelectionKeyHandler(){
> public void expire(Iterator<SelectionKey> keys){
> } // The connections are never going to be closed
> };
> * UDPWriteFilter Closes server socket after sending data too.
It close socket only when an exception happens. Are you seeing something
different? If yes, it means there is a bug :-)
Thanks so far for the feedback!
-- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>