On Aug 11 2013 11:12 AM, Michael Haberler wrote: > Am 11.08.2013 um 18:34 schrieb EBo <[email protected]>: > >> On Aug 11 2013 10:14 AM, Michael Haberler wrote: >>> > ... > >>> no, all I am saying is: client code might ask more than once for >>> the >>> completion of the current ticket/command - easy to do by caching >>> the >>> last ticket and status. >> >> makes sense, but I am not sure that this will be sufficient. > > insufficient to do what? > >> Were you >> able to guarantee before hand that the ticket ordering was not >> munged? > > Not sure what I'm supposed to guarantee? > > I replace the current method by one where submitters can uniquely > identified so they can be indiviudally acknowledged and the ack > tagged > with an event sequence number, and assure only one entity is > operating > on that global event sequence.
that sounds very good. my prior questions had to do with other systems that I have worked on (in multi-path packet transfers) where we had to reassemble the ordering stream and determine if we lost anything. If you are simply replacing the functionality without adding any additional latencies, then there should not be any issues. Part of my confusion is that we have been discussing ZMQ, EtherCAT, and lots of other things. I have not been tracking all the different threads well enough to know which of the email threads were related (and several of them could well easily been). EBo -- ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
