| Re: [cf-dev] Replacing the element-connector with Netty -- thoughts? |
|
The considerations on the element-connector are not about removing the modularity between network and protocol stage.
They are about how to package the different network stages. The default transport is UDP and deployments should use DTLS by default (we are past the interoperability issues of CoAP itself). This default is basically Scandium. The element-connector does so
little here, that I do not see the reason to keep it stand-alone (when we created it, we just wanted to have the flexibility of a package in case we discover new requirements; we did not). Next to UDP+DTLS, a TCP-based transport is coming up. This should go into a separate network stage package. Since we need
something scalable here, I still think Netty is a good choice here (given there will be long-lived TCP connections). A new package in the future might be an SMS binding. For all these we need to find a common interface. Since Simon has
experience with Netty, I think it is a good idea to use the TCP package to explore the Netty interface. Personally, I was also interested how the Netty UDP implementation performs. However, I simply want to pick one that is most useful for the users of Cf.
Since Julien has quite some experience here, I value his input on this. I hope this clarifies my conclusions ;) Ciao Matthias From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hudalla Kai (INST/ESY) I think Julien is right with his arguments against the feasibility of NIO in the context of UDP based protocols. However, I cannot really follow
the conclusions Matthias draws from these arguments. If the overall goal is to keep Californium decoupled from a particular transport implementation then we definitely need a set of interfaces providing this abstraction. My understanding is that this was the
primary role of the element-connector in the past. Is it about getting rid of element-connector as a separate bundle/jar but keeping the interfaces (e.g. Connector and RawDataChannel) and simply moving these interfaces to e.g. Scandium, or is it about replacing
the interfaces currently defined by element-connector with some other interfaces defined elsewhere (e.g. some abstractions defined by Netty)? I currently do not have a problem with using the interfaces defined by element-connector, regardless of whether they
are defined in a separate bundle/jar or as part of Scandium … Kai Von:
cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Kovatsch Matthias 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. Yes, I came to a similar conclusion in my paper on Californium where I compare several Web server architectures. 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. Here, I was interested in this „zero copy“ mechanism and wanted to see the impact. Netty is highly active and I saw
impressive results for Vert.x, so I was hoping for some good solutions for UDP in there as well. While I looked into scalability for the re-implementation of Californium, I wouldn’t say I am an expert on this topic… Thanks Julien for the good insights! 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). Simon, this is up to you then, I guess. What kind of architecture are you expecting: Cf as a LWM2M server that has thousands of parallel, long-lived
TCP connections? Or will there be many sleepy nodes and you will primarily have short-lived TCP connections? For the first, Netty is great. For the latter, “old sockets” and multi-threading is better.
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. So Scandium should become the overall transport provider with DTLS and UDP? That would work when we can make it clear (“security” in the project
description might be a bit confusing). Matthias |