Ethereal-users: [Ethereal-users] Re:[Q-waaaayOT] Size of a trace and hub functions
On 9 Feb 2001, at 13:53, Guy Harris wrote:
> > Actually my theory is that I have a "big pipe/small pipe" (Ethernet
> > 100 Mbps --> 56 frame relay --> Ethernet 100 Mbps) type of
> > environment/problem, and I think I am loosing (discarded) frames,
>
> ...and they're not getting retransmitted by TCP? (See "end-to-end
> argument". :-))
TCP "bullet-proof" reatransmission :-) ... you have to be kidding
NOTE: see also some of the comments from Barry Margolin on the
TCP/IP newsgroups in regards to his theory about even possible
patterns of data resetting CSU/DSUs on their passage through
frame circuits, making unusable any "retransmision" (as the data
will always stay the same), unless changing the data pattern
altogether (proven once on one of my circuits, when only changing
some of the files made them transmittable).
In the specific case I am talking about now it looks like a too
long "train" of not-yet ack-ed packets (because of big receiving
window size) let to the dissapearance of one packet in the middle,
never caught at the other end, thus never ack-ing the whole "train"
... no retransmission being able to repair ... and FTP servers
closing "cleanly" because of that. But I would like to have ethereal
capture this ...
I have - so far - decreased the receiving window size (obvious attempt),
and I have reduced the number of failures, but I fear to go below 8K, as
the delay caused by ack-ing more often than that is totally unacceptable
(even with this window size, from the original 32K, I hear complaints about
the additional delay). I have yet to see the TCP retransmission being of
any help in such cases ... :-(
> Perhaps the FTP servers and clients you're using both suck, so that they
> won't report a "connection timed out" error (or perhaps the OS on one
> side or the other sucks and doesn't provide a "connection timed out"
> indication on reads or writes)
<snip>
I will have to admit that this might be the case ... but I am "stuck"
with both ends - one being an OS/390 TCP/IP implementation (the
"client" for FTP), and the other a Netware 5.x (latest) for the stack
servicing either the Novell FTP server, or the Murkworks one (which
makes me believe that FTP sever implementation itself has nothing
to do wtih the problem - the more so that the Murkworks one is
probably the best by-the-book/RFC FTP design I have seen).
Re-reading the above I think I went beyond any acceptable level for
the ethereal list ... I am just hoping that these comments might
raise somebody's awareness and/or knowldge ... thanks again for
the extraordinary patience some of you had - so far - in listening to
my "wining" and trying to help me ... if anybody thinks that the
problem itself can be further discussed, I will dare to take this "off-
line", as it might not have anything to do with ethereal (if I find other
means of capturing my data).
Thx again (especially to Guy Harris and Diana Eichert),
Stef