taking python enterprise level?...
nanyaks at googlemail.com
Mon Mar 1 15:42:28 CET 2010
On Feb 26, 10:19 am, "Diez B. Roggisch" <de... at 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... at 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?
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
More information about the Python-list