Python 1.6 alpha 1 released
bellman at lysator.liu.se
Wed Apr 5 00:18:42 CEST 2000
"Fredrik Lundh" <effbot at telia.com> wrote:
> 1) stumbled upon one today: it turned out that by changing from 1.3
> to 1.5.2, large data transfers from a high-performance server to clients
> on an 10 Mbit Ethernet were unexpectedly terminated. the same trans-
> fers worked just fine with high-performance workstations, on an FDDI
> network. ten guru points to anyone who can explain why.
Sounds like problem with segmentation on the different frame sizes
of Ethernet and FDDI. Probably you were using TCP, and switching
to Python 1.5.2 made you send data that didn't fit inside an
Ethernet frame (1500 octets, including IP and TCP headers). The
sending TCP stack thus split the stream into several TCP segments.
The program that received the data wasn't prepared for the fact
that TCP can segment data any which way it wants to, and broke
when the socket didn't return the entire record in one read(2).
The data didn't grow to overflow the 4352 octet MTU for FDDI
frames, thus the TCP stack still used only a single segment then.
Classic bug. I have seen it in several programs. The latest
example is from the IP masquerading code in Linux kernels, at
least of 2.0 and 2.2 vintage. (Of course, *I* have never made
that mistake. That I know of, at least...)
Of course, that is only my first guess. There could be other
reasons. One possibility could be that your programs were timing
sensitive, and the lower speed of 10 Mbit/s Ethernet triggered the
bug. And I could probably think up other explanations that fit
the information you have given us. But I believe TCP segmentation
is the most probable.
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"Beware of bugs in the above code; I have ! bellman @ lysator.liu.se
only proved it correct, not tried it." ! Make Love -- Nicht Wahr!
More information about the Python-list