Hi Arthur,
I've implemented multibinding transports for TCP and UDP, by changing
SocketBinder API, but just a little bit different way, than you propose.
> What will be interesting from my point of view :
> - we have to have a possibility to 'address' local binding so my
> preposition is to introduce ServerConnection
IMHO we can reuse common Connection API, and transports like TCP and
UDP can have own TCP, UDP ServerConnection implementation, cause I'm
not sure which additional operations ServerConnection interface should
declare.
> - ServerConnection will have many useful methods, for
> example .unbind() (it should be here, not in the Transport)
ServerConnection has method close, which seem to do what you need.
SocketBinder bind(...) methods return Connection (server connection).
I've added SocketBinder.unbind(Connection) method, which works the
same way as Connection.close().
There is one more additional method SocketBinder.unbindAll(), which
unbinds and closes all the transport's server connections.
>
> - transport.bind() method returns Future<ServerConnection> (just
> like .connect() returns Future<Connection> )
IMHO, it doesn't make much sense, because even in NIO bind operation
gets executed immediately, so we can return ready Connection.
> - add events : BINDED and UNBINDED
> - in methods .handleBinded() and .handleUnbinded() in FilterAdapter
> we can obtain ServerConnection from sth like ctx.getServerConnection()
Do you have any specific usecase for those methods? Cause once
bind(..) operation returns ready bound Connection, there might be no
reason for these additional EVENTS and methods.
>
> - allow to have multiple bindings per Transport so it will be very
> universal (one Transport and many connections, many local bindings)
Agree. Done.
> You can see that everything about ServerConnection is very similar
> to Connection and .handleConnected() / .handleClose() methods and
> that is the way I see it.
> I know that you already have class called 'ServerConnection',
> probably you can do a little rename/refactoring since we need to
> have class like that for the end-client-side.
As I mentioned, if you have specific usecase for ServerConnection,
handleBind(...) etc - we might think about adding them, but currently,
IMHO, transport.bind(...), transport.unbind(Connection) could be enough?
> I hope you will do something in this direction, because I am not a
> fan of 'one binding per Transport', also added .unbind() method is
> very useful (thanks!) but there should be a better place for it.
> ServerConnection class allow to clean up all binding things in the
> same way as Connection do it for connections.
Agree.
> What you thing about it ?
> If you will file an issue please post a link ;)
Sure :)
Great feedback!
Thank you very much!
WBR,
Alexey.
>
>
> I am sitting in java networking last 5 years so that are my
> thoughts. I don't like to fight with Selector every time I want to
> create client-server application. I hope new Grizzly 2.0 will meet
> my and other programmers needs.
>
> Best regards,
> Arthur.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>