Sorry. Mistake. Please ignore.
> On Oct 2, 2014, at 7:33 AM, Brian Hoffman <[email protected]> wrote: > > M > > Sent from my iPhone > >> On Oct 1, 2014, at 1:21 PM, Matthew Hawn <[email protected]> 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
