| Re: [cf-dev] Replacing the element-connector with Netty -- thoughts? |
|
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 |