[Dovecot] v2.0.alpha1 released

[Ed W]

Timo Sirainen wrote:
> On Thu, 2009-10-15 at 23:56 +0100, Ed W wrote:
>   
>> I'm currently having problems with my vpn when using a UK "Three" SIM.  
>> I haven't fully investigated, but I *think* it's because the IP changes 
>> regularly even while the connection is up and in progress?  I think this 
>> setup is rare, but exists (on some broadband connections also 
>> apparently?).  I actually think that in this situation all the tcp 
>> connections *should* die...?
>>     
>
> Not necessarily. Laptops don't kill existing WiFi connections when RJ45
> is plugged into them.

Actually you raise an interesting issue there and actually it would be 
worth doing a bit of experimentation to see what really happens.

What I think will happen depends on the circumstances:

- Wifi and Wired on the same network, no NAT: On most unix operating 
systems, plugging in a new net card simply changes the default gateway, 
so the existing connection will try and go out via the new gateway and 
assuming no clever firewall on the remote side and no NAT, then the TCP 
sequence numbers should match and the connection should continue normally...

- Wifi and Wired on the same network, but with a NAT: Now in this case I 
would expect the NAT not to know that the continuing TCP stream from a 
new IP address is connected with the old stream? I would imagine all 
kinds of things will break, but I wouldn't expect the connection to 
continue correctly?

- Wifi and Wired on Windows XP and earlier (possibly vista also?) - now 
XP does something clever, it appears to have connection tracking in 
place and once a connection is started on a given interface then that 
connection continues via the same interface even if the default gateway 
is changed, ie default gateway only affects new tcp connections and old 
connections are automatically routed through their initial net device. 
This allows you to do some funky stuff such as remote controlling a 
machine over a fast connection whilst getting it to connect to some 
dialup connection, you can continue to control the machine even after 
the dialup device is brought up, ie the remote control app doesn't 
suddenly switch to the new connection.  I'm not 100% sure, but I think 
if you kill the wifi connection then actually it will drop all TCP 
connections on the wifi interface rather than switching them to the 
wired interface - so I don't think it's actually possible to achieve the 
effect you described?

Curiously you can achieve the same effect on linux at least as the XP 
situation, but you need to add some extra firewalling rules to setup 
connection tracking. Read the LARTC faq for more...

So actually I think that your scenario is actually quite rare?  In 
general I think the connection will die (for the mobile user).  I think 
the main situation where the connection won't die is only where you have 
wired/wireless connected to the same subnet and you switch between 
them.  In general I don't actually mind if my imap connection drops 
while switching and it seems low priority to preserve it, but agree it's 
desirable if it's possible

>  Perhaps mobile phones can also use 3G for some
> connections and when WiFi shows up starts using them for the new
> connections. Why should it kill any existing connections in those
> situations?
>   

I don't think it will kill the existing connections, but I think either 
it will switch them incorrectly (and they will die) or else they will 
continue in place over their respective networks (which may not actually 
be what the user wishes in the case of imap connections...)

Additionally it's hard to distinguish between one device using two net 
connections and two devices each on different/same connections...



>> I think the main cases to optimise for are a) mobile users behind a NAT, 
>> b) users possibly leaving one desktop machine on broadband, but checking 
>> the same account via a mobile device (same login). I think this coverst 
>> the 90% situation?
>>     
>
> I think including only username in the hash works nicely for just about
> everyone. I now committed the code:
> http://hg.dovecot.org/dovecot-1.2/rev/373b22cbabac
>   

Well, I would claim that it's only *important* to *synchronise* 
communications with a hash of username+IP (where IP is a proxy for 
communication interface in use on a given device).  I can't immediately 
see the implications of syncing all communications with a given user, 
but I think it's possible to be more specific if this is useful?

The logic is that we want the radio card to be as idle as possible for 
as long as possible, so we can treat a wifi interface and a 3G interface 
as separate problems and keep them both quiet for as long as possible.  
The point is once we wakeup say the wifi card we desire ONLY to wakeup 
the wifi card and additionally to get as much done as possible before we 
stick it back in idle so that we can maximise it's next idle period.  
Same also with the 3G card.  Of course if we can get away with waking up 
only one of the cards and NOT the other card then this is desirable 
because it's one less wakeup

Does that make sense? I think it argues in favour of tracking idle per 
user, per network card - given this is hard to do in the general case I 
think it suggests that tracking username + IP may be beneficial in terms 
of syncing communication and batching packets?


Turning it around, a typical use case might be to assume one user, one 
mailbox, one username/login, but two email programs in use simultaneously:

- User sits in office using office wifi/wired network to read email on 
desktop. a) device uses same subnet and hence same NAT, b) device uses 
3G connection. In both cases the desktop machine will be generating 
traffic and the device sits idle and we want to minimise wakeups to the 
device

- User leaves office, office machine remains on and IDLEing, but 
otherwise unused.  Device and desktop now on different networks.  User 
is a) leaving device in pocket, so also idling or b) actively using 
device, ie generating traffic - in both cases the desktop is also 
idling, but we desire to minimise the effects that idle causes on the 
device wakeups

Next usecase is:

One user, multiple mailboxes, multiple email programs...  Eg I have a 
desktop machine and mobile device, I also have a personal email address, 
main office sales address and main office support email address.  At the 
moment we use one username for each mailbox and in the case of the 
sales/support accounts we have every desktop user login with the same 
username for each account (eg everyone logs in as both sales@ and support@)

- In this case I desire to sync IDLE packets for multiple username 
combinations, but going back to the same IP address, ie actually I want 
to minimise wakeups per device and per device interface, ie if my 3G 
card wakes up then I want to get all the data in for all three logins...

How can I address this use-case? Perhaps in this case its better to use 
a single login and make the other accounts shared subfolders of that 
account?  This isn't something I have tried so far though?

Cheers

Ed W