Re: PPP is slow (and so is TCP!) [with fixes]

Eric Schenk (schenk@cs.toronto.edu)
Fri, 12 Apr 1996 11:33:09 -0400

Bernd Wiebelt <bernardo@studi.mathematik.hu-berlin.de> writes:
>
>I had some problems with pre-87-kernels, they used to
>hang on specific http/www-sessions, and even better,
>these hangs were reproducible (always at the same place).
>
>With 1.3.87 this works somehow, in a quite funny way:
>There are servers working under http, while they do not
>work under ftp.
>
>For me, ftp.uni-paderborn.de:/pub/doc/guitar is such a location.
>Works under http, but when I do a "dir", the ftp-session hangs.
>
>You may also want to try out "http://happypuppy.com/games/lordsoth"
>which does not work at all (I get 167 bytes until connection dies).

The removal of the tcp_send_ack in bad_tcp_sequence turns
out to have been a bad idea (TM). I stupidly forgot that
more than one ACK packet can be lost at a time. (doh)
To avoid retransmission storms with Solaris we probably still
want to make this a delayed ack, but we should probably at
least put an ack in there.

Try changing the code to bad_tcp_sequence() in tcp_input.c
to the following:

static void bad_tcp_sequence(struct sock *sk, struct tcphdr *th, u32 end_seq,
struct device *dev)
{
if (th->rst)
return;

/*
* Send a reset if we get something not ours and we are
* unsynchronized. Note: We don't do anything to our end. We
* are just killing the bogus remote connection then we will
* connect again and it will work (with luck).
*/

if (sk->state==TCP_SYN_SENT || sk->state==TCP_SYN_RECV)
{
tcp_send_reset(sk->saddr,sk->daddr,th,sk->prot,NULL,dev, sk->ip_
tos,sk->ip_ttl);
return;
}

tcp_send_delayed_ack(sk, HZ/2);
}

I've got to go and do some real work right now, so I haven't tested
this yet. If you try it let me know how it works...

-- eric

---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto