Active Topics
-
HDMI with Leste (1)
to Maemo 7 / Leste by teroyk - 1 day, 13 hrs ago -
Firefox with Leste (9)
to Maemo 7 / Leste by teroyk - 3 days, 15 hrs ago - more...
|
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..
 |
|
2010-04-11
, 13:47
|
|
Posts: 64 |
Thanked: 20 times |
Joined on Dec 2009
@ Adelaide, Australia
|
#33
|
+1 to that ^
|
|
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
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
 |
|
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
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?
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
The key words are "in flight". Take a peek at this netcat trace:
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)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
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.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.