Hi, off the top of my head, the publisher knows when a subscriber is registering to a channel, in that moment it could send the messages to that channel, you will need to wait until the sub is ready (there is a sample of pub sub with handshake) so it won’t lose messages.
I still think it can be done with pub/sub and a littke side code, however, there are multiple solutions to your problem, could you condense all stock info and send them in a single message? That way you could use a mix of pub/sub for live streaming and req/rep to get historical data On Fri, Dec 14, 2018 at 15:15 codyq0987 <[email protected]> wrote: > Hello Matteo, > > First of all, the application keeps generating data stream into DB no > matter whether there are clients or not. > Second, most of time, each topic ONLY goes to one client and we can > assume each client has different interest. > > For example, > > The application keeps saving all stocks current prices into DB. > ClientA needs the stock price for IBM since 8:30AM. > ClientB needs the stock price for Apple since 8:30AM. > When the sever receives the request from ClientA, it only sends the > IBM stock price to ClientA and only send Apple stock price to ClientB. > > A publisher has no connected subscribers, then it will simply drop all > messages. > For example, > Given the above example, if we see a clientC requesting stock price for > Apple. > The clientB and clientC cannot share the same pub/sub because all > previously published Apple price will be invisible to the later > jointed clientC. > So the server has to start a new session for clientC instead of asking > ClientC to subscribe the Apple topic. > > I don't see how the pub/sub pattern directly fits this usage. > > Thank you > > > > On Fri, Dec 14, 2018 at 2:39 PM Matteo <[email protected]> wrote: > > > > Hi, > > > > i believe pub/sub is the best approach. > > The publisher holds all the logic on sending based on time. > > > > At the end of the pubblication the pub could send a termination message > and shutdown if necessary. > > > > Does it make sense? > > What was holding you? > > > > Regards > > > > > > On Fri, Dec 14, 2018 at 14:31 codyq0987 <[email protected]> wrote: > >> > >> Hello all, > >> > >> I have an application that keeps computing stream data from T1(i.e 8:00 > AM) to T2(i.e. 10:00 AM). I want to utilize the pyzmq to serve the data to > clients by building a data service based on ZMQ. > >> > >> Here is the user cases: > >> > >> For example, > >> Case 1> if a client connects to the server @8:10 AM, the server will > send all old data before 8:10 AM and all new updates to the client. The > client will get data based on the submitted topic. > >> > >> Case 2> If the client connects to the server @7:00 AM, the server > simply does nothing and will send updates to the client after 8:00AM and > close the connection @10:00AM. > >> > >> Case 3> If the client connects to the server @11:00 AM, the server will > send all available data from 8:00AM-10:00AM to the client and then close > the connection. > >> > >> Note: if two clients connect to the server, each of them will get the > full data starting from 8:00AM. > >> > >> Based on my understanding, I cannot find any of the standard message > patter that is suitable for this purpose. > >> > >> PAIR > >> Client/Server > >> Publish/Subscribe > >> Push/Pull > >> > >> Question> In my use case, how I should implement the client/server with > ZMQ and which messaging pattern I should use? > >> > >> Thank you > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > -- > > Sent from iPhone > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Sent from iPhone
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
