NIO is buggy, complex, badly documented and slower than old-IO out-of-the-box. So we worked on frameworks for hidding it and adding all the bug workaround and performance tricks and also adding facilities for decoding message in TCP streams.
NIO is useful when you have a large number of sockets (like for a highly concurrent TCP client/server with a lot of connections). On low number of socket old IO (old Sockets API) is 30% faster.
With UDP you never never need to use NIO because you have only 1 socket (but NIO support UDP which is missleading...). So you don't need one of those NIO-framework.
Of course netty/mina can bind old IO socket for the sake of compatibility, but if you read the code of netty/mina you will understand it doesn't worth the added complexity (specially netty code :)
So I'm OK to use Netty for the TCP implementation (even if I do it myself I would just use old-IO for the client and java 7 NIO.2 for the server).
I'm not OK at all to use a NIO based framework for Californium UDP server/client, for the shake of simplicity and limiting dependencies. Even if it's for just using a couple of interface.
I agree this Element-connector project should not exist, but it's absolutely not solving the same problem as netty/mina. If it's just for decoupling Californium and Scandium projects, I think we can do it with Cf depending on Scandium and a couple of interface.
Julien
On Wed, Mar 18, 2015 at 8:39 AM Hudalla Kai (INST/ESY) <
Kai.Hudalla@xxxxxxxxxxxx> wrote:
BTW I'd be very interested to hear Julien's opinion regarding Netty. Since he is project lead of Apache Mina, he might have better insight into its feasibility for the purpose. Julien might also provide some pros & cons of Netty vs. Mina. As far as I understand, both frameworks address similar problems/issues ... but that's only my first impression after flying over the documentation.
Kai
> -----Ursprüngliche Nachricht-----
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@eclipse.org] Im
> Auftrag von Kovatsch Matthias
> Gesendet: Dienstag, 17. März 2015 19:45
> An: Californium (Cf) developer discussions
> Betreff: [cf-dev] Replacing the element-connector with Netty --
> thoughts?
>
> Hi all
>
> I have been thinking about getting rid of the element-connector since I
> created it. It was introduced to decouple Scandium from Californium, so
> that it can be used as stand-alone DTLS implementation. Netty [1] is a
> powerful framework that provides something similar (actually much
> more). While getting rid of the custom element-connector, it might also
> lead to a performance gain.
>
> Since Simon Lemay is now working on the TCP/TLS binding, it appears to
> be a good time to start with the replacement. Simon checked that Netty
> is also supported by Android and runs on the Raspberry Pi.
>
> Any comments? Does anyone have experience with Netty, maybe situations
> where it actually did not fit?
>
> For the long-term, it might also help for DTLS. Netty does not have
> DTLS yet, but I would say they need it. Scandium is by no means a high-
> performance implementation and still requires lots of work, in
> particular for testing and security analysis. But maybe we can get more
> contributors or an alternative that is better for both communities!
>
> Ciao
> Matthias
>
> [1] http://netty.io/
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
