On Feb 26, 10:19 am, "Diez B. Roggisch" <de...@nospam.web.de> wrote: > Am 26.02.10 05:01, schrieb D'Arcy J.M. Cain: > > > > > On Fri, 26 Feb 2010 01:12:00 +0100 > > "Diez B. Roggisch"<de...@nospam.web.de> wrote: > >>> That better way turned out to asynchronous update transactions. All we > >>> did was keep feeding updates to the remote site and forget about ACKS. > >>> We then had a second process which handled ACKS and tracked which > >>> packets had been properly transferred. The system had IDs on each > >>> update and retries happened if ACKS didn't happen soon enough. > >>> Naturally we ignored ACKS that we had already processed. > > >> sounds like using UDP to me, of course with a protocol on top (namely > >> the one you implemented). > > >> Any reason you sticked to TCP instead? > > > TCP does a great job of delivering a stream of data in order and > > handling the retries. The app really was connection oriented and we > > saw no reason to emulate that over an unconnected protocol. There were > > other wheels to reinvent that were more important. > > So when you talk about ACKs, you don't mean these on the TCP-level > (darn, whatever iso-level that is...), but on some higher level? > > Diez
i think its on the TCP that he's referring to or is it?... if it is, that means he's doing some 'mean' network level scripting, impressive...but i never thought python could go that deep in network programming!... -- http://mail.python.org/mailman/listinfo/python-list
