directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (DIRSEDA-10) UDP Imeplementation
Date Sun, 26 Sep 2004 05:49:32 GMT
The following comment has been added to this issue:

     Author: Trustin Lee
    Created: Sat, 25 Sep 2004 10:48 PM
I'm implementing UDPListenerManager and I encountered a few problems:

1. ClientKey.<init> pre-generates clientId as a string and it can cause performance
degradation for UDP impl because ClientKey is instantiated everytime UDPListenerManager receives
a datagram packet.  The solution could be:

- making clientId as an integer
- providing ClientKeyCache with LRU maps (I prefer this)

2. ClientKey accepts only Socket in the constructor, and this cannot be applicable to DatagramChannels,
so it should be changed to accept Channels (possibly SelectableChannel).  But we also have
to consider intra-VM pipe which does not have any NIO channels.

So it is supposed for us to revamp ClientKey now. :)  I'll think about this and add more comments
to this issue.
View this comment:

View the issue:

Here is an overview of the issue:
        Key: DIRSEDA-10
    Summary: UDP Imeplementation
       Type: Task

     Status: Open
   Priority: Major

    Project: Seda Framework

   Assignee: Alex Karasulu
   Reporter: Trustin Lee

    Created: Mon, 20 Sep 2004 9:53 PM
    Updated: Sat, 25 Sep 2004 10:48 PM

SEDA framework currently supports TCP/IP only.  Supporting UDP is the primary concern to make
it widely usable.  But because of its essential difference with UDP, we have to approach carefully.

Datagram channels does not have notion of connect/disconnect.  DatagramChannel.validOps()
does not include OP_ACCEPT, so UDPListenerManager and UDPInputManager should be incorporated,
and it is slightly different from current routing process of SEDA.  This difference must be
handled smoothly to resolve this issue.

Because there is no explicit connection/disconnection notification, the policy how we should
maintin and expire ClientKeys.  Simplistic implementation will have an timeout-based expiration
mechanism.  As an alternative, SEDA can give up managing the sessions of UDP events although
I'm not sure it is possible.

Any ideas?

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message