Closed sharpe5 closed 8 years ago
You can also consider not using the pub sub pattern. Router dealer with kind of login handshake. Also every new subscriber gets all history messages? On Feb 13, 2016 13:23, "sharpe5" notifications@github.com wrote:
Currently, the codebase passes all of its tests and works reliably for me.
However, if we wanted to eliminate the 500ms delay on subscription instantion, we could potentially do this by ensuring that the subscriber thread is up and running before connecting.
— Reply to this email directly or view it on GitHub https://github.com/NetMQ/NetMQ.ReactiveExtensions/issues/23.
I absolutely agree. This is the direction the design is heading in, see issues #7 and #12.
There are two broad aims for this library: 1). A simple API. 2). It just works.
Currently, 1) is looking good, but 2) is not quite there. The main problems are: a) The subscriber might miss messages if it connects after the publisher has published some items; b) We have to have a separate port and TCP/IP connection for every new ISubject of T.
Once we address these, the library will be a lot closer to "just working". There are a few other enhancements such as MsgPack support and a dynamic/floating daemon, but these can be handled later.
I've had a lot of experiencing writing C# wrappers over Tibco, and the aim is to eliminate all of the sloth dung that Tibco tends to shovel at its developers.
Currently, the codebase passes all of its tests and works reliably for me.
However, if we wanted to eliminate the 500ms delay on subscription instantion, we could potentially do this by ensuring that the subscriber thread is up and running before connecting.