You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Jörg Henne <j....@levigo.de> on 2006/03/27 21:28:32 UTC
Broadcast end DHCP
Hi all,
today I had a quick first look at the issue of implementing (or rather
continuing the existing work for) the DHCP protocol support. The notion
was that DHCP can't be completed until mina supports broadcast.
Well, I feel this might end up as the most stupid question in this (and
several other) mailing-list's history, but what I see is that
- there is already some code in place to support broadcast in MINA, e.g.
the line
ch.socket().setBroadcast( cfg.isBroadcast() );
in DatagramAcceptorDelegate.registerNew().
- if one configures the MINA server like this:
IoAcceptor acceptor = new DatagramAcceptor();
IoAcceptorConfig config = new DatagramAcceptorConfig();
((DatagramSessionConfigImpl)config.getSessionConfig()).setBroadcast(true);
acceptor.bind(
new InetSocketAddress( 67 ),
new DhcpProtocolHandler(),
config );
the server receives broadcasts just fine.
- sending data to the broadcast address worked for me, too, with minimal
changes to DhcpProtocolHandler.messageReceived():
InetSocketAddress inetSocketAddress = new InetSocketAddress(
InetAddress.getByName("255.255.255.255"), PORT);
ConnectFuture future = connector.connect(inetSocketAddress,
new DhcpProtocolHandler());
After all, I don't see that broadcast doesn't work with NIO. What
doesn't work with NIO, however, (at least as I see it) is multicast. But
multicast is a totally different beast and not required for DHCP.
So, well, the question is: as this sounds too good, to be true - what
did I miss?
Joerg Henne
Re: Adding ThreadPools Filters to connectors and acceptors
Posted by Trustin Lee <tr...@gmail.com>.
Hi Serkan,
On 3/29/06, Serkan Demir <se...@oksijen.com> wrote:
>
> Hello,
> I have been implementing peer-to-peer message processing and sending
> mechanism by using MINA. I have examined all examples. I have a question
> on addition of thread pools filters to connectors and acceptors. I have
> been using a modified version of SimpleServiceRegistry for server-side
> actions and using its thread pool filters for socket protocol acceptor.
> On the same process, i have added a IoProtocolConnector for connecting a
> peer and opening a session. Do I have to add thread pool filters to my
> connector for scalability similar to below lines? If answer is yes, may
> i use the same thread pool which i used for acceptors? Or should i
> create and use a new pool ?
>
> connector.getIoConnector
> ().getFilterChain().addFirst("threadPool",ioThreadPoolFilter);
> connector.getFilterChain().addFirst("threadPool",
> protocolThreadPoolFilter);
You can use the same thread pool. A thread pool can be shared by multiple
services, but it can be risky when one service locks down the pool.
As of MINA 0.9.3, you don't need to add a thread pool by yourself. It is
added by default.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Adding ThreadPools Filters to connectors and acceptors
Posted by Serkan Demir <se...@oksijen.com>.
Hello,
I have been implementing peer-to-peer message processing and sending
mechanism by using MINA. I have examined all examples. I have a question
on addition of thread pools filters to connectors and acceptors. I have
been using a modified version of SimpleServiceRegistry for server-side
actions and using its thread pool filters for socket protocol acceptor.
On the same process, i have added a IoProtocolConnector for connecting a
peer and opening a session. Do I have to add thread pool filters to my
connector for scalability similar to below lines? If answer is yes, may
i use the same thread pool which i used for acceptors? Or should i
create and use a new pool ?
connector.getIoConnector().getFilterChain().addFirst("threadPool",ioThreadPoolFilter);
connector.getFilterChain().addFirst("threadPool",
protocolThreadPoolFilter);
thanks lot,
Serkan
Re: Broadcast end DHCP
Posted by Jörg Henne <j....@levigo.de>.
Enrique Rodriguez schrieb:
> Trustin Lee wrote:
> ...
>>> After all, I don't see that broadcast doesn't work with NIO. What
>>> doesn't work with NIO, however, (at least as I see it) is multicast.
>>> But
>>> multicast is a totally different beast and not required for DHCP.
>>> So, well, the question is: as this sounds too good, to be true - what
>>> did I miss?
>>
>> It didn't work when Enrique tried to implement broadcasting with MINA
>> last
>> time. If it works, it's a very great news. :)
>
> I haven't tried in a while, so that is great news. Some of your code
> example is new API. New since last January 2005 when I last looked,
> that is. We need more eyes on these protocols so I'll be happy for
> any work that you can contribute.
while my primary goal is to implement a DHCP proxy (with "proxy" being a
misnomer, but that's the jargon, anyway) to supply additional boot-time
information in a PXE boot environment, I'll hopefully be able contribute
useful stuff for a general-purpose DHCP server.
I noticed that the code to send DHCP replies is rather complicated and
it seems that each reply leaves a lingering thread behind. Is this
necessary because MINA doesn't support the unconnected datagram mode
where the socket isn't connected to a fixed destination, and instead
each message is outfitted with a destination SocketAddress? Setting up a
connection for each reply seems rather wasteful. Shouldn't rather mina
be extended to support sending to a per-message destination socket address?
Joerg Henne
Re: Broadcast end DHCP
Posted by Enrique Rodriguez <en...@gmail.com>.
Trustin Lee wrote:
...
>> After all, I don't see that broadcast doesn't work with NIO. What
>> doesn't work with NIO, however, (at least as I see it) is multicast. But
>> multicast is a totally different beast and not required for DHCP.
>> So, well, the question is: as this sounds too good, to be true - what
>> did I miss?
>
> It didn't work when Enrique tried to implement broadcasting with MINA last
> time. If it works, it's a very great news. :)
I haven't tried in a while, so that is great news. Some of your code
example is new API. New since last January 2005 when I last looked,
that is. We need more eyes on these protocols so I'll be happy for any
work that you can contribute.
Enrique
Re: Broadcast end DHCP
Posted by Trustin Lee <tr...@gmail.com>.
On 3/28/06, Jörg Henne <j....@levigo.de> wrote:
>
> Hi all,
>
> today I had a quick first look at the issue of implementing (or rather
> continuing the existing work for) the DHCP protocol support. The notion
> was that DHCP can't be completed until mina supports broadcast.
>
> Well, I feel this might end up as the most stupid question in this (and
> several other) mailing-list's history, but what I see is that
> - there is already some code in place to support broadcast in MINA, e.g.
> the line
> ch.socket().setBroadcast( cfg.isBroadcast() );
> in DatagramAcceptorDelegate.registerNew().
> - if one configures the MINA server like this:
> IoAcceptor acceptor = new DatagramAcceptor();
> IoAcceptorConfig config = new DatagramAcceptorConfig();
>
> ((DatagramSessionConfigImpl)config.getSessionConfig()).setBroadcast(true);
> acceptor.bind(
> new InetSocketAddress( 67 ),
> new DhcpProtocolHandler(),
> config );
> the server receives broadcasts just fine.
> - sending data to the broadcast address worked for me, too, with minimal
> changes to DhcpProtocolHandler.messageReceived():
> InetSocketAddress inetSocketAddress = new InetSocketAddress(
> InetAddress.getByName("255.255.255.255"), PORT);
> ConnectFuture future = connector.connect(inetSocketAddress,
> new DhcpProtocolHandler());
>
> After all, I don't see that broadcast doesn't work with NIO. What
> doesn't work with NIO, however, (at least as I see it) is multicast. But
> multicast is a totally different beast and not required for DHCP.
> So, well, the question is: as this sounds too good, to be true - what
> did I miss?
It didn't work when Enrique tried to implement broadcasting with MINA last
time. If it works, it's a very great news. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6