maemo.org - Talk - [Under consideration] 3G Throttler (Battery Saver)

Quote:

Originally Posted by TA-t3 (Post 395608)

This is true. It can be handled though, by layering a virtual network on top of the physical network, for example.

Yes, see mobile IP and VPNs.

They doesn't work as well as protocols which detect a failed connection and restart, like IM protocols, but they do work.

I use a VPN to reach my server from my laptop for this reason - so that I can continue with SSH connections after the IP connection has broken and restarted with a different IP when tethering through a phone.

But I found that it can take an annoyingly long time after the connection is restarted before the SSH will resume. This is not due to SSH, but due to TCP sometimes not responding quickly to a resumed underlying connection, once it's got into slow retransmit mode. Once it has recovered, it's fast again.

Now I use GNU Screen on the server and that's much better :)

Quote:

Er, no, it doesn't. Not at all. You may add a timeout at another layer (e.g. ssh often has one), but there's not one inherent for delayed data. TCP/IP's timers start to pop in when you're disconnecting (there's one typically at 120 seconds, another near 15 minutes etc.)
If it couldn't survive a 120 second holdup during data streaming it wouldn't be very useful in a lot of normal, day-to-day conditions. TCP/IP was _designed_ to survive such things. I wasn't kidding when I described my over-the-night resurrection of a data transfer.

I have just tried it, to check if I was mistaken, and it did timeout.

The key words are "in flight". Take a peek at this netcat trace:

Code:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3

fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0

connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("A.B.C.D")}, 16) = -1 EINPROGRESS (Operation now in progress)

select(4, NULL, [3], NULL, NULL) = 1 (out [3])

getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0

fcntl64(3, F_SETFL, O_RDWR) = 0

poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN}], 2, -1) = 1 ([{fd=3, revents=POLLIN}])

read(3, "SSH-2.0-OpenSSH_4.3p2 Debian-9et"..., 1024) = 36

write(1, "SSH-2.0-OpenSSH_4.3p2 Debian-9et"..., 36) = 36

poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN}], 2, -1) = 1 ([{fd=0, revents=POLLIN}])

read(0, "x\n", 1024) = 2

write(3, "x\n", 2) = 2

poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN}], 2, -1) = 1

read(3, 0xbfdf3bc8, 1024) = -1 ETIMEDOUT (Connection timed out)

That opened a TCP/IPv4 socket, no special options (in particular no keepalive options), on a bog standard Linux.

The ethernet cable was removed from the laptop after opening the connection, and before typing "x" and therefore before the write() call. There is no significance to the fact it's using an SSH port, because what happens remotely is irrelevant once the cable is removed

TCP tried to transmit the packet containing "x" for about 15 minutes, before giving up and reporting ETIMEDOUT.

It took about 15 minutes - I'd mistaken the 120 seconds for something else. Oops :) Here is the reason for 15 minutes:

Code:

tcp_retries2 - INTEGER

        This value influences the timeout of an alive TCP connection,

        when RTO retransmissions remain unacknowledged.

        Given a value of N, a hypothetical TCP connection following

        exponential backoff with an initial RTO of TCP_RTO_MIN would

        retransmit N times before killing the connection at the

        (N+1)th RTO.



        The default value of 15 yields a hypothetical timeout of 924.6

        seconds and is a lower bound for the effective timeout.

        TCP will effectively time out at the first RTO which exceeds

        the hypothetical timeout.



        RFC 1122 recommends at least 100 seconds for the timeout,

        which corresponds to a value of at least 8.

You can change the tunable if you wish.

If you don't have data in flight, and no keepalives or applications timeouts, this doesn't happen - you can indeed resume any amount of time later. That's a basic property of TCP/IP.

But most application protocols do, of course, transmit something from time to time - otherwise they wouldn't be able to tell the difference between a temporarily lost link and one which is permanently gone, to be cleaned up.