cbaxter / infinitymq Goto Github PK

Implement core message reader/writer infrastructure.

Requires:

• MessageWriter and Frame Chunking.
• MessageReader and Frame Demultiplexer.

MessageWriter currently adds a 'Type' header to all messages sent; eventually will need to support custom message headers.

Although ReceiveAsync tends to incur extra overhead due to context switching; coupled with a BlockingCollection may allow for FrameReader to continue to working while pulling off more data from socket connection.

I think this would add to the .NET-ness of the project and make consuming things easier.

It already has an API around subscribing and would fit perfectly into an app.

See:
http://msdn.microsoft.com/en-us/library/ee850490.aspx
http://msdn.microsoft.com/en-us/library/dd990377.aspx
http://blog.rjcox.co.uk/2010/01/10/iobservable-req/

MessageReader assumes a single type frame followed by one or more content flags without actually verifying FrameFlags.

MessageReader & MessageWriter are currently dependant on FrameReader & FrameWriter. For in process communication, serialization is not required and as such, in process versions of each class will be required.

Currently header frames are just a payload; no method currently exists for identifying a particular header frame .

InfinityMQ should support ZeroMQ Message Transport Protocol/1.1. The spec is listed as "Raw" (i.e., not stable), but it will likely become stable when zmq 3.1 is officially released in a few months.

This will allow IMQ apps to interact with anything built on ZMQ, which is a major advantage for heterogeneous deployment scenarios.

Intra-process communication doesn't need to use ZMTP, although it could. ZMTP will be most useful for inter-process and networked communication.

Allow for multiple bindings or connect calls on a single channel to various end points. Should be able to bind multiple endpoints such as TCP/IPC etc through a single channel. Should not be able to intermix bind and connect calls on same channel.

Sockets implement custom send that accepts collection of buffers; thus would no longer require Buffer.BlockCopy to build up single message buffer. Determine impact on performance and act accordingly.

Draft first version of public API.

Several options should be made to be configurable (defaulted) at the App.config/Web.config level.

Examples.

• Socket.SendBufferSize
• Socket.ReceiveBufferSize
• BufferedFrameWriter.BufferSize
• BufferedFrameReader.BufferSize
• etc.

As raised in Issue #2; implement ZeroMQ Message Transport Protocol (ZMTP) Frames as described in http://rfc.zeromq.org/spec:15

We should pick an open source license for IMQ (∞MQ?).

Options:

• LGPL — allows for dynamic linking in proprietary code, but disallows modification and re-distribution under more a more permissive license. Any forks or derived works would have to remain LGPL or transition to GPL.
• AGPL — similar to LGPL, but if users run a custom fork on a server (i.e., used, but not explicitly distributed), they are required to release their modifications under a compatible license.
• Apache — unlike *GPL, does not require modified versions to be distributed with the same license. In theory, this would allow someone to sell modified, closed-source versions of IMQ as long as they retained the original Apache NOTICE file with our names in it. At least, that is my non-lawyer understanding.
• MIT or BSD — similar to Apache, in that modified versions can be distributed/sold with any license as long as the original copyright notice with our names is maintained.

ZeroMQ uses a modified LGPL that also allows static linking to proprietary code, but this doesn't really apply in .NET land.

MongoDB uses AGPL for the database itself and Apache for the drivers. 10gen also sells commercial licenses for the database for those who need to tweak but don't want to release their changes.

I'm leaning toward either LGPL or AGPL. What are your thoughts?

The current Type header format in MessageWriter should be profiled and improved if possible/necessary.

The performance impact of using a versionless AQN may not matter with large messages, but it could become an issue for small messages, especially if a compact binary serializer is used (i.e., protobuf).

Required/desirable properties for Type encoding:

• Deterministic and consistent, even across process & machine boundaries
• Filterable - should be in such a format that a subscriber could easily ignore messages based on the type header without a lot of computation
• Small and fast

To facilitate maximum throughput, create buffered frame reader/writer classes.

Expected Results:

Named Pipes (4096 bytes x 1,000,000)

PUB/SUB Channel

• Message Latency = 3.16 [us]
• Message Throughput = 158211.52 [msg/s]
• Data Throughput = 5184.28 [Mb/s]

Create basic console application to allow for measuring benchmarks of different InfinityMQ setups.

• Should be single process
• Should be easy to add new benchmarks (i.e., implement IBenchmark)
• Initially populate with baseline tests.

Currently using Uri class to specify endpoint; should validate that Uri is valid based on scheme.

NOTE: In case of TCP need to be able to handle DNS vs IP Address etc.

Implement buffer pool to prevent reallocation of byte arrays for temporary message buffers.

Due to each write on a named pipe being treated as a single message; don't want to write out frames individually (seriously degrades performance). Implement buffer pool to allow for more efficient memory management.