Page 4 of 4 « First 23 4
Reply
Thread Tools
jjx is offline jjx
2009-11-30 , 00:15
Posts: 474 | Thanked: 283 times | Joined on Oct 2009 @ Oxford, UK
#31
Originally Posted by TA-t3 View Post
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

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.
 
chrisp7 is offline chrisp7
2010-01-11 , 16:12
Posts: 515 | Thanked: 193 times | Joined on Oct 2009
#32
Anyone interested in this now the N900 is out? It would be so much better than toggling it yourself. It just needs to toggle to 3G when certain apps are open/opened then toggle back when specified apps are closed..
 
The Quote Train's Avatar
The Quote Train is offline The Quote Train
2010-04-11 , 13:47
Posts: 64 | Thanked: 20 times | Joined on Dec 2009 @ Adelaide, Australia
#33
+1 to that ^
 
cliffordpascal is offline cliffordpascal
2010-04-11 , 14:21
Posts: 20 | Thanked: 26 times | Joined on Jan 2010
#34
I was thinking of this app ever since I found out that you could toggle between 2g/3g connections (and that was the first day I got the phone when it was launched at the uk nokia store)

I think this is an excellent idea. Do developers really need convincing that such functionality is really worth consideration at all?.....of course it is..... come on now guys or girls....it'll be an absolute godsend!

The phone should default to 2g mode and when the browser is activated then it automatically switches to 3g. When the browser is closed there should also be a timeout then the phone reverts back to 2g mode.

some other fancy options should include that when a particular application is started, should it need to retrieve data from the internet, then a setting should allow the user to again automatically switch to 3g.

A tyical application which would be a good candidate for this functionality would be something like a stock trading program which constantly looks for live data feeds.

C
 
Flandry's Avatar
Flandry is offline Flandry
2010-04-11 , 20:55
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#35
I think that's all covered by Shepherd.
__________________

Unofficial PR1.3/Meego 1.1 FAQ
***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Reply
Page 4 of 4 « First 23 4

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 04:08.

Contact Us - Home - Archive - Top