Just to clarify , the customer entitlement issue just means that each customer doesn’t see the raw market rate. They have a different percentage increase applied depending g on who they are. It’s cheaper for big customers
The reason I mentioned this is to make the point that there is not one stream of data for each current pair. It’s different depending on who you are . That is all handled by the downstream service . But the implication for the new app is that you need to create a new connection to the down stream app for each incoming client request Hope that makes sense Chris On Wed, 13 Dec 2017 at 12:05, Stephen Gray <riskybizl...@live.com> wrote: > Chris, have you seen the Clone Pattern? > http://zguide.zeromq.org/php:chapter5 > > > > Essentially it solves the ‘late joiner’ issue of PUB-SUB by providing a > back channel using ROUTER-DEALER over which any missing data (or data > history) can be requested and delivered. You might be able to come up with > a way to use the back channel to co-ordinate your different customer > entitlement. Possibly prepend all exchange rate data points on the PUB-SUB > with a UUID, set the client to filter on the SUB socket by the UUID. The > client gets knowledge of the correct UUID by requesting it over the > ROUTER-DEALER at which point you verify that the client has entitlement > before issuing. Or something? > > > > Stephen > > > > *From:* zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] *On > Behalf Of *Chris Catherall > *Sent:* 13 December 2017 09:16 > *To:* zeromq-dev@lists.zeromq.org > *Subject:* [zeromq-dev] Streaming data > > > > Hi > > We are building an application which delivers currency exchange rates to > customers over the web. > > The exchange rates come from an existing .net WCF Duplex service. And the > rates are streamed for a period of 60 seconds over a tcp connection. i.e. > constantly changing data (one or two updates per second), not a single > request/response. > > Also, different pricing is applied depending on who the customer is, so it > is not a single source of data. It is different for each customer. And so a > new instance of the data stream is created for each incoming request. > > We are building a new API which would sit in front of the existing WCF > service (and behind the website backend) and we are considering using Zero > mq to distribute the rates. > > So it is server-to-server comms. (**Not** the browser to server part) > > > > I am trying to identify if I should use a stream socket > > http://hintjens.com/blog:42 > > > > Or if a simple REQ/REP pair would be fine. Or if there is some other > pattern that is more appropriate. > > > > Some things I'm struggling with: > > > > Given the data is different for each request I presume I cant have a > single RES server. I'd need to new one up for each incoming request? How > would that work? > > Also, how would you then co-ordinate the correct data is returned to the > correct client? > > Could the zeroMQ part be hosted inside an existing .net Web.api ? > > > > thanks for any advice > ------------------------------ > > This message may contain confidential or privileged information. If you > have received this message in error, please immediately notify us by email > at disclai...@moneycorp.com or by telephone before permanently deleting > it. If you are not the intended recipient, do not use, copy or disclose the > information contained in this message or in any attachment. > > The views expressed may not be the views of Moneycorp and should not be > relied upon. Please note that Moneycorp monitors e-mails sent and/or > received; further communication will signify your consent to this. Please > be aware that emails and attachments may contain viruses. > > Unless expressly stated otherwise, none of the information contained in > this email constitutes or should be construed as financial advice. No > payment card information should be transmitted by email from or to > Moneycorp beyond the first six and last four digits of any payment card > (credit or debit card). In no circumstances should the card security code > CVV (3 digit number on the reverse) be transmitted. > > TTT Moneycorp Limited (company number 738837) is registered in England. > Its registered office is at Floor 5, Zig Zag Building, 70 Victoria > Street, London, SW1E 6SQ > <https://maps.google.com/?q=70+Victoria+Street,+London,+SW1E+6SQ&entry=gmail&source=g>. > Moneycorp is a trading name of TTT Moneycorp Limited which is authorised > and regulated by the Financial Conduct Authority for the provision of > payment services (firm reference number 308919). > > -- > > Chris Sent from Gmail for IPhone > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Chris Sent from Gmail for IPhone
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
