| Re: [cf-dev] Replacing the element-connector with Netty -- thoughts? |
hey all,I think the level of effort to get an initial assessment if it at least it “fits” well is not too big.Later version of netty work on Android and it seems to be doing fine on the RPi from what i can read,As for scandium, i do agree that to provide an alternative to BC is a good idea and perhaps community like netty would embrace the addition. It would for sure give tremendous visibility on the project as Netty is quite active.I will try to see how add Netty goes and post my finding here, this way we can all assess the LOE and feasibility and make a wiser decisioncheersSimon_______________________________________________On Mar 18, 2015, at 2:23 PM, Kovatsch Matthias <kovatsch@xxxxxxxxxxx> wrote:_______________________________________________The element-connector and Californium already have independent concurrency models, decoupled by a (Executor) queue. The idea would be to first change the interface “on the bottom of Californium” to the Netty interface to plug in different protocol implementations by Netty (primarily TCP for the binding Simon is working on). If Netty is too heavy-weight for some platforms/applications, we could refactor the UDPConnector to comply with this interface. However, I was thinking that we could gain some performance on high-end servers and Linux when using Netty also for UDP. Maybe I can find some time for benchmarks.,,If the interface change works out well, I was thinking about “Scandium 2.0”. Scandium never looked into efficient ways to implement DTLS, the handshake, etc. Before rolling it out to production servers, I personally would re-implement Scandium with the lessons learned---as I did with Californium. And we should aim for some collaborations with other projects that look for a DTLS implementation to have enough manpower for good code quality. Bouncy Castle is currently the only alternative in Java. But should we go for a monoculture? And by that time, we might actually already be looking at DTLS 1.3…CiaoMatthiasFrom: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Julien Vermillard
Sent: Mittwoch, 18. März 2015 08:52
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Replacing the element-connector with Netty -- thoughts?Arg typo: (I'm quite sure NIO frameworks doesn't make sense for UDP servers)Hi,Netty is quite big compared to element-connector. it's comming with it's own threading model, and without rewriting the threading part of Californium it doesn't make sense for the UDP server. (I'm quite sure NIO frameworks make sense at all for UDP servers)
Having a dependency to netty for the TCP implementation is ok, for calfornium/scandium, UDP, I don't think it's a good idea for just implementing the Channel interface.
If the goal is to make Scandium consumable by netty user, let's just create a scandium-netty project implementing the netty Channel interface?
JulienHi 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
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