directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (DIRSEDA-10) UDP Imeplementation
Date Wed, 13 Oct 2004 06:43:52 GMT
The following comment has been added to this issue:

     Author: Trustin Lee
    Created: Tue, 12 Oct 2004 11:43 PM
UDP implementation and TCP implementation differs in its nature; UDP is stateless, so there
is no borderline of ListenerManager and InputManager.  Alex and I discussed on creating an
abstraction layer to generalize both.

After considering this, I faced the question, 'is an abstraction layer required?'  I think
having it or not is not an important problem because we have a frontend which lets users do
not care about it.

So I propose arranging packages and classes like this:

* BindPoint (formely ListenerConfig)
* AcceptionMonitor (formerly ListenerManagerMonitor)
* ReadMonitor (formerly InputManageMonitor)

* TcpBindPoint

* TcpAcceptor (formerly ListenerManager)
  has an AcceptionMonitor
* TcpReader (formerly InputManager)
  has a Readmonitor

* UdpReader
  has both AcceptionMonitor and ReadMonitor

Any critics and ideas are welcome!
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: Tue, 12 Oct 2004 11:43 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