M Sent from my iPhone
> On Oct 1, 2014, at 1:21 PM, Matthew Hawn <matth...@donaanacounty.org> wrote: > > There a several things I see that could make CurveZMQ a lot better. I would > be happy to help, but these may require more knowledge of ZMQ internals than > I know. Yet. Some of them may need a Curve mechanism version bump. In any > case, I wanted to bring them up for discussion: > > Message Size Limits > It behooves a pubic server to not accept large messages until authentication > happens. Without a message limit, unauthenticated clients can easily get > the server use up all available memory. On the other hand. authenticated > clients are trusted and should be able to send large messages. This > asymmetry cannot be handled with a single ZMQ_MAXMSGSIZE. However, during > the security handshake, we know exactly what size packages to accept. We > just need to somehow communicate this to the lower levels. > > Memory Usage > There is currently several large buffers that are only used during handshakes > but kept for the whole session. 160 bytes per client on server. 288 bytes > on client. By freeing these after handshake, we can increate the number of > simultaneous client connections. > > Zero State Initial Connections > The protocol enables the server to keep zero state until the client has > authenticated. This would allow public servers to mitigate DOS attacks much > more effectively. However, implementing this would require DEEP changes in > ZMQ: socket, session, stream_engine, mechanism, and so forth. > > Invalid Message Handling > After the handshake is completed, it seems to make sense to drop invalid > messages rather than killing the entire connection. I tried to return a > simple EAGAIN instead of EPROTO, but this just prevented the server from > processing messages. > > Message Command > Currently, after the handshake, CurveZMQ sends messages back and forth > prefixed with a "\7MESSAGE". Do we really need to have this for EVERY > message? > > Certificate Exchange > It would be nice to have a protocol level mechanism for exchanging > certificates before authentication. This is not about certificate format or > validation mechanisms, just a way to exchange the cert blobs and call on the > application to do validation. I am currently working on a proof-of-concept > and will share more with the group later. > > Crypto Library > tweetnacl - very small, adequate speed and cross-compatibility. This is > already included with zmq, but only the CMAKE tools use it. I think this > should included in the build by default for both CMAKE and autotools > > libsodium - better cross-compatibility. May be slightly faster than > tweetnacl. May be an option to use if tweetnacl cannot compile correctly > > nacl - fast, hard to compile. Maybe an option for those who want the fastest > speed. Does not include ed25519, but that is not used explicitly by libzmq. > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
