> The bad network behavior was due to shared irqs somehow screwing
> things up. This explained most but not all of the problems.
ah, that's why your test pgm succeeded on my systems..
> When I last posted I had a reproducible test case which spewed a bunch
> of packets from a server to a cli
SUMMARY:
The bad network behavior was due to shared irqs somehow screwing
things up. This explained most but not all of the problems.
DETAILS:
Many people emailed me that they were experiencing similar problems.
Even though the cause of my problem is not kernel related, I'm hoping
my narrative
> Btw: can the aplication somehow ask the tcp/ip stack what was
> actualy acked?
> (ie. how many bytes were acked).
No, and you shouldn't want to know. Even if the other end ACKed the data,
that doesn't mean that the application on the other end didn't crash. So it
won't tell you what yo
On Tue, 19 Jun 2001, Jonathan Morton wrote:
> > > > > Btw: can the aplication somehow ask the tcp/ip stack what was
> >> >actualy acked?
> >> >> (ie. how many bytes were acked).
> >> >
> >> >no, but it's not necessarily a useful number anyhow -- because it's
> >> >possible that the remote
> > > > Btw: can the aplication somehow ask the tcp/ip stack what was
>> >actualy acked?
>> >> (ie. how many bytes were acked).
>> >
>> >no, but it's not necessarily a useful number anyhow -- because it's
>> >possible that the remote end ACKd bytes but the ACK never arrives. so you
>> >c
On Mon, 18 Jun 2001, Jonathan Morton wrote:
> > > Btw: can the aplication somehow ask the tcp/ip stack what was
> >actualy acked?
> >> (ie. how many bytes were acked).
> >
> >no, but it's not necessarily a useful number anyhow -- because it's
> >possible that the remote end ACKd bytes but the
> > Btw: can the aplication somehow ask the tcp/ip stack what was
>actualy acked?
>> (ie. how many bytes were acked).
>
>no, but it's not necessarily a useful number anyhow -- because it's
>possible that the remote end ACKd bytes but the ACK never arrives. so you
>can get into a situation wher
On Mon, 18 Jun 2001, Jan Hudec wrote:
> Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked?
> (ie. how many bytes were acked).
no, but it's not necessarily a useful number anyhow -- because it's
possible that the remote end ACKd bytes but the ACK never arrives. so you
c
> > TCP is NOT a guaranteed protocol -- you can't just blast data from one
> port
> > to another and expect it to work.
>
> Isn't it? Are you really sure about that? I thought UDP was the
> not-guaranteed-one and TCP was the one guaranting that all data reaches the
> other end in order and all. P
On Sun, 17 Jun 2001, Dan Podeanu wrote:
> Is there any logical reason why if, given fd is a connected, AF_INET,
> SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd);
> to the peer, over a rather slow network (read modem, satelite link, etc),
> the data gets lost (the remote rece
On Sun, Jun 17, 2001 at 05:13:43PM -0400, Albert D. Cahalan wrote:
> > Is there any logical reason why if, given fd is a connected, AF_INET,
> > SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd);
> > to the peer, over a rather slow network (read modem, satelite link, etc),
> > t
Alan Cox <[EMAIL PROTECTED]> writes:
> > > Specifically
> > > 1.If the receiver closes and there is unread data many TCP's forget
> > > to RST the sender to indicate that data was lost.
> >
> > Do at least FreeBSD, Solaris and NT sent RST correctly?
>
> I dont believe so
There is als
On Sun, Jun 17, 2001 at 08:17:27PM +0200, Pavel Machek wrote:
> > 2. There is a flaw in the TCP protocol itself that is extremely unlikely
> > to bite people but can in theory cause wrong data in some unusual
> > circumstances that Ian Heavans found and has yet to be fixed by
> > the
> > Specifically
> > 1. If the receiver closes and there is unread data many TCP's forget
> > to RST the sender to indicate that data was lost.
>
> Do at least FreeBSD, Solaris and NT sent RST correctly?
I dont believe so
> > 2. There is a flaw in the TCP protocol itself that is extremely
In order to figure out what this problem is I'm going to add some
printk statements in the networking code on the client machine.
Hopefully, this will show me what's going on. My goal is to trace the
receipt of the datagram by tcp, see why/how it's deciding to ack or
not ack, and then trace the s
OK guys -- how much money are you willing to be that TCP is guaranteed??
Since you don't want to talk OSI that's OK -- that's just to educate some
people.
Try this: (this is what I ran into years ago and had to argue to death).
#1 Client1 has tcp connection to Server1. Both machines are setup t
First a little more data on the problem.
1) I've never seen it with the client and server program on the same
computer.
2) It only repros on some systems. If I can repro it on some systems
and then make the client the server and the server the client the
bug will often fail to repro.
On Fri, 15 Jun 2001, Mike Black wrote:
> This is a very common misconception -- I worked a contract many years ago
> where I actually had to quote the author of TCP to convince a banking
> company I was working with that TCP is not a guaranteed protocol.
> Guaranteed delivery at layer 5 - yes -
> TCP is guaranteed delivery at layer 5 -- but that's all -- not a "guaranteed
> protocol"
For certain specific cases this is in itself not true either. Also for many
many implementations.
Specifically
1. If the receiver closes and there is unread data many TCP's forget
to RST the s
Mike Black writes:
> I'm concerned that you're probably just overruning your IP stack:
...
> TCP is NOT a guaranteed protocol -- you can't just blast data from one port
> to another and expect it to work.
Yes you can. This is why we have TCP in fact.
> a tcp-write is NOT guaranteed -- and as yo
My home page
FAX 321-676-2355
- Original Message -
From: "Heusden, Folkert van" <[EMAIL PROTECTED]>
To: "Mike Black" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 8:53 AM
Subject: RE: Client receives TCP packets but does not ACK
> TCP is NOT a guaranteed protocol -- you can't just blast data from one
port
> to another and expect it to work.
Isn't it? Are you really sure about that? I thought UDP was the
not-guaranteed-one and TCP was the one guaranting that all data reaches the
other end in order and all. Please enlighte
e -
From: "Robert Kleemann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 11:50 PM
Subject: Re: Client receives TCP packets but does not ACK
A couple people have requested a test case.
The problem first showed up in a very large java app. Since the
A couple people have requested a test case.
The problem first showed up in a very large java app. Since then I
wrote a small perl program to duplicate the behavior of the large app
by sending the same data, in the same order, in the same sized blocks,
from the server to the client.
If you want
On 13 Jun 2001, Andi Kleen wrote:
> The packet likely doesn't fit into the socket buffer and is silently
> dropped. The TCP stack doesn't force an ACK in this case, but it
> probably should, although it wouldn't solve the deadlock. The deadlock
> will be only solved if the local application reads
Robert Kleemann <[EMAIL PROTECTED]> writes:
> I have a client server program that opens a tcp connection between two
> machines. Everything is fine until a certain type of data is sent
> across the socket at which point the client refuses to ACK and the
> server continues to resend the packets t
I have a client server program that opens a tcp connection between two
machines. Everything is fine until a certain type of data is sent
across the socket at which point the client refuses to ACK and the
server continues to resend the packets to no avail.
I've verified that the client is blockin
27 matches
Mail list logo
