[
https://issues.apache.org/jira/browse/AXIS2-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871884#action_12871884
]
Andreas Veithen commented on AXIS2-4724:
----------------------------------------
I'd rather propose the following approach. Extract an interface from the
current IODispatcher and have two implementations: NonBlockingIODispatcher
(with the existing code from IODispatcher) and BlockingIODispatcher. Looking at
the public methods of IODispatcher, it should be fairly easy to reimplement the
same interface with blocking I/O:
addEndpoint(Endpoint)
removeEndpoint(Endpoint)
stop()
One would then have a single UDPListener, but the type of IODispatcher would be
configurable. In a second step, multicast support would be introduced into
BlockingIODispatcher (with the necessary changes in the IODispatcher interface
and the Endpoint class). Of course, any attempt to use multicast together with
NonBlockingIODispatcher would result in an error.
There will be also two other points we have to look into:
1. The source port in the responses sent by the transport should actually be
the port on which the request has been received (i.e. if the request goes from
port X to Y, then the response should go from Y to X, not from some random port
to X). This is necessary to properly correlate request and responses and also
because most UDP clients expect that. This implies that the response must be
sent using the DatagramSocket or DatagramChannel on which the request was
received (and which is managed by the listener!).
2. Currently, request-response uses a blocking I/O call. However, it should be
possible to support a true asynchronous invocation style (i.e. doing
request-response without blocking a thread).
The first point is tricky because it is not possible to mix blocking and non
blocking mode with a single DatagramSocket/Channel. Thus, if the listener uses
non blocking I/O, the sender also needs to use it. The second requirement can
only be supported with non blocking I/O. Probably what we will have at the end
is a design where the UDPListener and UDPSender use a shared IODispatcher
instance which is either non blocking (and supports truly asynchronous
request-response) or blocking (and supports multicast).
> Add Multicast Capabilities to the UDP Transport
> -----------------------------------------------
>
> Key: AXIS2-4724
> URL: https://issues.apache.org/jira/browse/AXIS2-4724
> Project: Axis2
> Issue Type: Improvement
> Components: transports
> Reporter: Hiranya Jayathilaka
> Fix For: 1.6
>
>
> With this improvement Axis2 will be able to receive SOAP messages from
> multicast groups and send requests to multicast groups. Also we will be able
> to support multicast request - unicast response MEP. I will attach the patch
> soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
