Great thanks! the fact that each UDP message comes in its own buffer and
MINA recycles datagram session clears most of the questions for me.
The bit I mentioned about 40 seconds - what I saw was that after ~40
seconds of receiving the last datagram message, the "ExpiringMapExpirer"
thread comes in and closes the UDP session. After that if the server
receives a datagram from the same client, it creates a new IoSession. Is
that expected?


On Thu, Oct 11, 2012 at 12:42 PM, Emmanuel Lécharny <[email protected]>wrote:

> Le 10/11/12 7:46 AM, Dhruv Chopra a écrit :
>
>  Hi,
>>
>> I am trying to understand how MINA server does session management for UDP
>> clients.
>> Now for TCP sessions (with Nagle ON)
>>
> What for ??? Nagle algorithm is a TCP parameter, it's totally ingnored for
> UDP...
>
>
>  , if I send multiple messages my client
>> in a loop I see that they often arrive in a single IoBuffer. And of course
>> the IoSession remains the same.
>>
> Each UDP message that arrives on the clint side will arrive in its own
> IoBuffer :
>
>     private void readHandle( H handle ) throws Exception
>     {
>         IoBuffer readBuf = IoBuffer.allocate( 
> getSessionConfig().**getReadBufferSize()
> );
>
>         SocketAddress remoteAddress = receive( handle, readBuf );
>
>         if ( remoteAddress != null )
>         {
>             IoSession session = newSessionWithoutLock( remoteAddress,
> localAddress( handle ) );
>
>             readBuf.flip();
>
>             session.getFilterChain().**fireMessageReceived( readBuf );
>
>         }
>     }
>
>  When I similarly send multiple messages from my UDP client - I was
>> expecting that a new IoSession will be created for every packet because of
>> the connectionless nature of the protocol and hence they will arrive in
>> different IoBuffers.
>>
> No, we don't create a new session for every Datagram excahned. The session
> is created for a specific remote IP address and stored in a map, so that it
> can be reused the next time the user send a message :
>
>     private IoSession newSessionWithoutLock( SocketAddress remoteAddress,
> SocketAddress localAddress ) throws Exception
>     {
>         H handle = boundHandles.get( localAddress );
>
>         if ( handle == null )
>         {
>             throw new IllegalArgumentException( "Unknown local address: "
> + localAddress );
>         }
>
>         IoSession session;
>
>         synchronized ( sessionRecycler )
>         {
>             session = sessionRecycler.recycle( remoteAddress );
>
>             if ( session != null )
>             {
>                 return session;
>             }
>
>             // If a new session needs to be created.
>             S newSession = newSession( this, handle, remoteAddress );
>             getSessionRecycler().put( newSession );
>             session = newSession;
>         }
>
>         initSession( session, null, null );
>
>         try
>         {
>             this.getFilterChainBuilder().**buildFilterChain(
> session.getFilterChain() );
>             getListeners().**fireSessionCreated( session );
>         }
>         catch ( Throwable t )
>         {
>             ExceptionMonitor.getInstance()**.exceptionCaught( t );
>         }
>
>         return session;
>     }
>
> As you can see, if we find an existing session for a give address, we
> recycle it. We then spare the cost of initializing the session (creating
> the chain, etc)
>
> In any case, this is ortogonal to the way IoBuffer are handled. One
> Datagram = one IoBuffer.
>
>
>> However from my experiments - a datagram session
>>
> UDP session. Datagram is the data unit being transfered.
>
>    is getting closed only
>> after ~40 seconds and UDP messages come from the same session if sent less
>> than 40 sec apart.
>>
> Not sure that I get what you mean here.
>
>
>  Right now I am seeing that sending multiple UDP messages
>> come in different IoBuffers
>>
> No.
>
>
>    - is that guaranteed or is it possible for MINA
>> to accumulate them and give as one IoBuffer also?
>>
>
> What do you have in your chain ? Are you using a cumulative protocol
> decoder ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Reply via email to