| Re: [cf-dev] Replacing the element-connector with Netty -- thoughts? |
|
Matthias, I like your mentioning of “Scandium 2.0”. I understand that Scandium was initially created as an academic effort and was intended as a learning and research
project. However, I think we should start focusing on its appropriateness for production use cases. At Bosch we will definitely need a DTLS implementation that can support hundreds of thousands of devices. Thus, we are more than motivated to work on it.
I think that we will need to do some major re-factoring if not re-design in Scandium’s core areas. No matter what little improvement or fix I try to make, I
immediately run into problems due to the weak encapsulation and coherence of the classes. In particular, I think we need to better encapsulate the state machine for the handshake within the session (and the session alone). Right now, knowledge about the details
of the handshake is distributed over dozens of classes, making it very hard to do any kind of change without the risk of breaking everything else. Not to mention the lack of unit tests (or testability of the classes) adding to this problem as well … Maybe we could also do a face to face meeting and discuss some things we would like to address? I am often in Friedrichshafen and could easily fit in a trip
to Zurich in order to get things rolling … What do you think? Kai Von: cf-dev-bounces@xxxxxxxxxxx
[mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Kovatsch Matthias 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… Ciao Matthias From:
cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard Arg typo: (I'm quite sure NIO frameworks doesn't make sense for UDP servers) On Wed, Mar 18, 2015 at 8:44 AM Julien Vermillard <jvermillard@xxxxxxxxx> wrote:
|