Hi again Would be interested to hear if a async client server seems appropriate for the problem described previously. And if so, is there a pattern that allows the server to create more workers as the number of incoming requests increases
Thanks On Wed, 13 Dec 2017 at 13:50, Chris Catherall <chris.cather...@gmail.com> wrote: > 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 > -- Chris Sent from Gmail for IPhone
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
