[Dovecot] v2.0.alpha1 released
http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz.sig
So here's the first alpha version of Dovecot v2.0. There are still a couple of things left to do, but in general it should work for most people. I started using it for my own mails a few days ago and it seems to work without errors.
Largest changes since v1.2:
* Global ACLs are now looked up using namespace prefixes. For example
if you previously had INBOX. namespace prefix and a global ACL for
"INBOX.Sent", it's now looked up from "INBOX.Sent" file instead of
"Sent" as before.
+ Redesigned master process. It's now more modular and there is less
code running as root.
+ Configuration supports now per-local/remote ip/network settings.
+ dsync utility does a two-way mailbox synchronization.
+ LMTP server and proxying.
+ Added mdbox (multi-dbox) mail storage backend.
+ doveadm utility can be used to do all kinds of administration
functions. Old dovecotpw and *view utilities now exist in its
subcommands.Some things left to do:
Do something about backwards compatibility with v1.x. Either make it read v1.x config files or provide some config conversion utility.
dsync still has some bugs
config process is a bit too slow. config handling in general could use some caching all around. no need to ask configuration for each login unless there are per-remote-ip settings.
some kind of an optional connection policy server could be useful. mainly to finally implement tcp-wrappers support.
mail_uid, mail_gid, mail_chroot settings don't really work now. I think this actually needs a bit larger change, which is probably a good idea in any case:
After successfully authenticating, login process needs to get imap/pop3 process executed. Currently this is done by transferring the connection fd to master process, doing userdb lookup and then forking and execing the imap/pop3 process.
The new behavior I'm thinking is that after auth, login process would connect to imap/pop3 unix socket in the login/ directory. That would cause master process to fork a new imap/pop3 process (running as root). Login process would send the necessary auth information via the unix socket, possibly transfer also the fd, and imap/pop3 would do the userdb lookup and then drop privileges.
This change has some pros:
- Master process will no longer temporarily hold some extra fds and use extra memory during auth lookups. If auth process is hanging these could cause problems.
- Master process will no longer have any special auth handling code and I can remove type=auth-source and type=auth services.
- Of course fixes the mail_* setting issue, because all of this is now done by imap/pop3 process, which knows about these settings.
- Creating support for "multiple imap/pop3 post-login connections in a single process" should be pretty easy to implement with this. The imap/pop3 unix socket just needs to be listened by a new process in the middle that keeps track of what imap/pop3 processes exist and can redirect the new connections to those.
But also some cons:
- drop_priv_before_exec=yes no longer works, unless the uid/gid is hardcoded to the service {} block.
- Each imap/pop3 process needs to do a connect() to auth server at startup, adding a bit to the latency.
On Tue, Oct 13, 2009 at 1:45 AM, Timo Sirainen tss@iki.fi wrote:
http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz.sig
So here's the first alpha version of Dovecot v2.0. There are still a couple of things left to do, but in general it should work for most people. I started using it for my own mails a few days ago and it seems to work without errors.
On my FreeBSD 7.2-STABLE:
./configure
--cache-file=../cache_file
--prefix=/opt/dovecot2
--with-ioloop=kqueue
--with-notify=kqueue
--with-sql=yes
--with-mysql
--with-zlib
--with-bzlib
--with-ssl=openssl
--with-sql-drivers
And this is how I end up:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib
-I../../src/lib-test -I../../src/lib-charset -std=gnu99 -g -O2 -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT
mbox-from.lo -MD -MP -MF .deps/mbox-from.Tpo -c mbox-from.c -fPIC -DPIC -o
.libs/mbox-from.o
mbox-from.c: In function 'mbox_from_parse':
mbox-from.c:240: error: wrong type argument to unary minus
gmake[2]: *** [mbox-from.lo] Error 1
gmake[2]: Leaving directory
/usr/home/wash/Tools/Dovecot/dovecot-2.0/dovecot-2.0.alpha1/src/lib-mail' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory /usr/home/wash/Tools/Dovecot/dovecot-2.0/dovecot-2.0.alpha1/src'
gmake: *** [install-recursive] Error 1
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"If you have nothing good to say about someone, just shut up!." -- Lucky Dube
On Tue, 2009-10-13 at 18:00 +0300, Odhiambo Washington wrote:
On my FreeBSD 7.2-STABLE:
mbox-from.c: In function 'mbox_from_parse': mbox-from.c:240: error: wrong type argument to unary minus
Yeah, BSDs have a timezone() function instead of a timezone variable. I don't think the code is correct for Linux either.. I'll have to figure out something.
On 10/13/2009 05:00 PM Odhiambo Washington wrote:
On my FreeBSD 7.2-STABLE:
… mbox-from.c:240: error: wrong type argument to unary minus …
Timo has provided a few patches and fixed some issues. Since the changeset http://hg.dovecot.org/dovecot-2.0/rev/5147503f4123 Dovecot v2.0.alpha1 compiles and runs on FreeBSD 7.2. :-)
Regards, Pascal
The trapper recommends today: cafebabe.0928821@localdomain.org
Timo Sirainen wrote:
- Redesigned master process. It's now more modular and there is less code running as root
Hi, some really interesting stuff coming out of this. Looks cool!
Something I had been pondering recently (I started using a cell phone with imap idle support), was a previous poster mentioning the huge increase in battery life from turning off the radio for as long as possible. It appears that just turning on the radio (wifi or 3G) consumes much more energy than the transmitting of a few bytes of data after it's on. In particular synchronising certain types of infrequent transmissions may have a dramatic increase in battery life for mobile devices - I'm thinking mainly of the NOOPs when the connection is idling
Is this something that could be implemented with the current architecture? Are there other types of application where synchronising "stuff" happening to multiple connections from the same client could be helpful?
Just a thought...
Ed W
On Tue, 2009-10-13 at 21:38 +0100, Ed W wrote:
Something I had been pondering recently (I started using a cell phone with imap idle support), was a previous poster mentioning the huge increase in battery life from turning off the radio for as long as possible. It appears that just turning on the radio (wifi or 3G) consumes much more energy than the transmitting of a few bytes of data after it's on. In particular synchronising certain types of infrequent transmissions may have a dramatic increase in battery life for mobile devices - I'm thinking mainly of the NOOPs when the connection is idling
Is this something that could be implemented with the current architecture? Are there other types of application where synchronising "stuff" happening to multiple connections from the same client could be helpful?
No matter how many times I read the above, I've no idea what you're trying to ask. :) This seems like entirely a client-dependent issue and Dovecot can't much alter clients' behavior. Unless you're talking about running Dovecot on a cell phone?..
- Timo Sirainen dovecot@dovecot.org:
On Tue, 2009-10-13 at 21:38 +0100, Ed W wrote:
Something I had been pondering recently (I started using a cell phone with imap idle support), was a previous poster mentioning the huge increase in battery life from turning off the radio for as long as possible. It appears that just turning on the radio (wifi or 3G) consumes much more energy than the transmitting of a few bytes of data after it's on. In particular synchronising certain types of infrequent transmissions may have a dramatic increase in battery life for mobile devices - I'm thinking mainly of the NOOPs when the connection is idling
Idling consumes lots of battery on mobiles, because it requires an active TCP session. Cell phone providers use a trick to circumvent that. They send a SMS (with a service signature that hides it from regular SMS readers) containing a trigger signal which causes the mobile to check for new mail.
This uses less battery. You may want to check if you application/mobile supports this.
p@rick
Is this something that could be implemented with the current architecture? Are there other types of application where synchronising "stuff" happening to multiple connections from the same client could be helpful?
No matter how many times I read the above, I've no idea what you're trying to ask. :) This seems like entirely a client-dependent issue and Dovecot can't much alter clients' behavior. Unless you're talking about running Dovecot on a cell phone?..
Timo Sirainen wrote:
On Tue, 2009-10-13 at 21:38 +0100, Ed W wrote:
Something I had been pondering recently (I started using a cell phone with imap idle support), was a previous poster mentioning the huge increase in battery life from turning off the radio for as long as possible. It appears that just turning on the radio (wifi or 3G) consumes much more energy than the transmitting of a few bytes of data after it's on. In particular synchronising certain types of infrequent transmissions may have a dramatic increase in battery life for mobile devices - I'm thinking mainly of the NOOPs when the connection is idling
Is this something that could be implemented with the current architecture? Are there other types of application where synchronising "stuff" happening to multiple connections from the same client could be helpful?
No matter how many times I read the above, I've no idea what you're trying to ask. :) This seems like entirely a client-dependent issue and Dovecot can't much alter clients' behavior. Unless you're talking about running Dovecot on a cell phone?..
Perhaps I misunderstand, but doesn't dovecot send a "keepalive" on connections which are idling? It's been discussed on the list previously, google turns up this (not from the list, but related): http://doubleukay.com/node/12
I hadn't previously twigged for example that the real reason using my old Nokia N95 as a wifi SIP phone was caning the battery could have been the short re-registration interval as much as actually having the phone on wifi. I now have an N97 and the buggers disabled the SIP phone bit, but there is some hope it will be re-enabled on the next firmware update
- I was planning to do a bit of research on this if so.
The point being that for wireless users there is a massive "cost" to turn on the radio and transmit any data, the actual transmission of incremental data after that is cheap. So applications and servers which may operate over wireless networks can massively increase battery life if they give some thought to significantly "batching up" network traffic
I can imagine that in the case of a typical cell phone with say 3 email accounts, there will be likely three idle connections (or more) to dovecot and each will end up sending keepalive packets at slightly different intervals for each connection. By synchronising this network traffic you would potentially increase battery life by up to a factor of 3 (ie turn on the radio to send the keepalive for all connections in one go, rather than turning the radio on three times as often)... (I think perhaps that's optimistic, but you can see that quite large gains might be possible here)
Nokia make a rather neat battery optimisation tool which allows you to log power consumed very precisely (and hopefully to correlate it to what your app is doing) - I would like to find the time to break this out to have a closer peak at some of this stuff, but it remains on my todo list right now...
Cheers
Ed W
On Oct 13, 2009, at 6:28 PM, Ed W wrote:
Perhaps I misunderstand, but doesn't dovecot send a "keepalive" on
connections which are idling?
Yes, it's configurable nowadays:
# How many seconds to wait between "OK Still here" notifications when # client is IDLEing. #imap_idle_notify_interval = 120
And I did think of that in my previous mail, but then thought it
wasn't relevant because client was only receiving data, but now I
realized that of course the client will also have to send back TCP ACK.
I can imagine that in the case of a typical cell phone with say 3
email accounts, there will be likely three idle connections (or
more) to dovecot and each will end up sending keepalive packets at
slightly different intervals for each connection. By synchronising
this network traffic you would potentially increase battery life by
up to a factor of 3 (ie turn on the radio to send the keepalive for
all connections in one go, rather than turning the radio on three
times as often)... (I think perhaps that's optimistic, but you can
see that quite large gains might be possible here)
Oh. That does sound like a good idea. Hmm. I think there's an easy way
to implement this:
next_still_here_sending_timestamp = imap_idle_notify_interval - (time(NULL) + crc32(username)) % imap_idle_notify_interval;
The username CRC32 is there to avoid network/load spikes when all the
processes try to send the "Still here" at the same time.
Timo Sirainen wrote:
I can imagine that in the case of a typical cell phone with say 3 email accounts, there will be likely three idle connections (or more) to dovecot and each will end up sending keepalive packets at slightly different intervals for each connection. By synchronising this network traffic you would potentially increase battery life by up to a factor of 3 (ie turn on the radio to send the keepalive for all connections in one go, rather than turning the radio on three times as often)... (I think perhaps that's optimistic, but you can see that quite large gains might be possible here)
Oh. That does sound like a good idea. Hmm. I think there's an easy way to implement this:
next_still_here_sending_timestamp = imap_idle_notify_interval - (time(NULL) + crc32(username)) % imap_idle_notify_interval;
The username CRC32 is there to avoid network/load spikes when all the processes try to send the "Still here" at the same time.
Just to kick this around a bit - I guess it's possible for one username to be logged in on three different computers (eg I have several laptops with identical config and sometimes several of them are on at once). On the other hand my original idea was to compromise on "hashing" by IP address, this is obviously wrong in the sense that frequently multiple users are behind large NAT ranges, especially if they are on some sort of WAN connection
I don't think either situation is actually a "problem" because it would appear that the only "failure" mode is to send too few keepalives, sending a few too many now is unlikely to be a drain given we then send fewer subsequently.
However, I guess for maximum polish it would be optimal to hash based on both username and ip address? This would appear to be useful in your algorithm above anyway though?
Thanks for listening!
Ed W
On Wed, 2009-10-14 at 00:14 +0100, Ed W wrote:
next_still_here_sending_timestamp = imap_idle_notify_interval - (time(NULL) + crc32(username)) % imap_idle_notify_interval;
The username CRC32 is there to avoid network/load spikes when all the processes try to send the "Still here" at the same time.
Just to kick this around a bit - I guess it's possible for one username to be logged in on three different computers (eg I have several laptops with identical config and sometimes several of them are on at once). On the other hand my original idea was to compromise on "hashing" by IP address, this is obviously wrong in the sense that frequently multiple users are behind large NAT ranges, especially if they are on some sort of WAN connection
And it's especially bad if Dovecot is run behind proxy and doesn't know anyone's IP address.
However, I guess for maximum polish it would be optimal to hash based on both username and ip address? This would appear to be useful in your algorithm above anyway though?
I'm just wondering if some mobile networks can give you different IPs for different connections, like when you open first connection in area X and then move around to area Y and open another connection it gives you a new IP, but still keeps the old connections working? In that situation adding IP to the hash wouldn't be a good idea.
Timo Sirainen wrote:
On Wed, 2009-10-14 at 00:14 +0100, Ed W wrote:
next_still_here_sending_timestamp = imap_idle_notify_interval - (time(NULL) + crc32(username)) % imap_idle_notify_interval;
The username CRC32 is there to avoid network/load spikes when all the processes try to send the "Still here" at the same time.
Just to kick this around a bit - I guess it's possible for one username to be logged in on three different computers (eg I have several laptops with identical config and sometimes several of them are on at once). On the other hand my original idea was to compromise on "hashing" by IP address, this is obviously wrong in the sense that frequently multiple users are behind large NAT ranges, especially if they are on some sort of WAN connection
And it's especially bad if Dovecot is run behind proxy and doesn't know anyone's IP address.
I think under the most useful scenario of 3G/wifi networks, it's practically a given that there is a NAT involved...
However, I guess for maximum polish it would be optimal to hash based on both username and ip address? This would appear to be useful in your algorithm above anyway though?
I'm just wondering if some mobile networks can give you different IPs for different connections, like when you open first connection in area X and then move around to area Y and open another connection it gives you a new IP, but still keeps the old connections working? In that situation adding IP to the hash wouldn't be a good idea.
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...?
One of the problems I have been having is that with Thunderbird, assuming the IP *is* changing (not tested), it seems like my end of the link is continuing as though the connection is alive and the far end is obviously treating me as a new connection and the end result is a bunch of errors "server is not an IMAP4 server".
So my (unfounded) guess is that if the IP changes on you quietly, then actually the TCP connection will eventually fall apart and this is not a problem worth tracking on the dovecot side?
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?
Ed W
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. 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?
As for IP changing in 3G-only traffic.. Is it that much different from the above? I wouldn't ever want existing connections to be killed.
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
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
On Oct 16, 2009, at 7:54 AM, Ed W wrote:
Not necessarily. Laptops don't kill existing WiFi connections when
RJ45 is plugged into them.
- 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.
Do you mean those interfaces would have the same or different IPs?
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 -
Right.
so I don't think it's actually possible to achieve the effect you
described?
What I meant is what happens in most places where I plug in ethernet
cable while a wireless connection is already there: I get a new IP for
the wired connection. Then I have two IPs. Only one of the interfaces
is the default gateway. But there's nothing special going on, all
connections use their original local IP regardless of how the default
gateway is changed. If you kill one of the interfaces, all of its
conncetions will drop.
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?
Yes, the user+ip syncing is important. But I don't see any point in
adding the +ip part, since user-only syncing is just as good for most
people and better for a few others.
Next usecase is:
- 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...
Right, this is something that would require ip-only hashing. But I
think I prefer user-only hashing..
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?
Shared folders would be better typically, I think..
Hi
- 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.
Do you mean those interfaces would have the same or different IPs?
Usually different IPs. But Windows does some clever connection state tracking and keeps data going out of the same interface as where the connection was first started from... I'm not sure how/why, but it's actually quite useful!
so I don't think it's actually possible to achieve the effect you described?
What I meant is what happens in most places where I plug in ethernet cable while a wireless connection is already there: I get a new IP for the wired connection. Then I have two IPs. Only one of the interfaces is the default gateway. But there's nothing special going on, all connections use their original local IP regardless of how the default gateway is changed. If you kill one of the interfaces, all of its conncetions will drop.
Hmm, I haven't tested whether this is what actually happens on some unix'y OS, but I will take your word for it.
However, in the case above I'm not sure I understand your original point?
I think the goal is still to minimise the number of times we bring an interface into life (for mobile devices), so if for example your two hypothetical devices were instead a wifi and 3G connection, then plugging in the second device will mean we have some connections out through wifi and some out through 3G, they might both well be imap connections to the same server and using the same username, but ideally we want to treat each bunch of connections separately (and minimise the number of times we use each interface)
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?
Yes, the user+ip syncing is important. But I don't see any point in adding the +ip part, since user-only syncing is just as good for most people and better for a few others.
Well, I'm not going to over-argue the point, but right now I personally have both a desktop AND a mobile device (and expect this to be a common situation for most users with a mobile device), so in my case I prefer to have the mobile device talking as little as possible, and to distinguish the two devices we probably need to use something like IP as a proxy (not perfect of course because both could be behind the same NAT...)
I might be missing the point though, so I throw this up mainly as a data point...
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?
Shared folders would be better typically, I think..
I think this is something I will need to investigate further then...
The main problem is that it's hard to get any mobile devices with decent IDLE support and a decent folder implementation, expecting that app to ALSO be great at handling a nested folder of INBOX's scenario is going to be rather hit and miss... I will investigate Profimail on my N97 and see how it works (*excellent* app by the way - I don't mind plugging Profimail at all - better email app than most desktop programs!)
Cheers
Ed W
P.S. I posted some notes on zlib some time back - what kind of things could I do to increase the chance you might investigate supporting the COMPRESS extension in the near future? Obviously writing the code would be one option - would you perhaps mind pointing me towards the obvious spots to look at to do such an integration? I'm quite keen to give it a whirl because the Profimail guys very kindly implemented it recently and I'm hoping to see the new Thunderbird released sometime (in the next few years?) soon...!
On 10/16/2009, Ed W (lists@wildgooses.com) wrote:
Well, I'm not going to over-argue the point, but right now I personally have both a desktop AND a mobile device (and expect this to be a common situation for most users with a mobile device), so in my case I prefer to have the mobile device talking as little as possible, and to distinguish the two devices we probably need to use something like IP as a proxy (not perfect of course because both could be behind the same NAT...)
I agree that this use case will be more and more common with time.
Most of this conversation is over my head, but if there is no simple solution for distinguishing devices on the same inbound IP, maybe the 'best' solution would be to set up different named hosts to connect to (mobilemail.example.com vs imap/mail.example.com) and have each pointed to a different dovecot instance that is optimized accordingly?
On Fri, 2009-10-16 at 16:52 +0100, Ed W wrote:
What I meant is what happens in most places where I plug in ethernet cable while a wireless connection is already there: I get a new IP for the wired connection. Then I have two IPs. Only one of the interfaces is the default gateway. But there's nothing special going on, all connections use their original local IP regardless of how the default gateway is changed. If you kill one of the interfaces, all of its conncetions will drop.
Hmm, I haven't tested whether this is what actually happens on some unix'y OS, but I will take your word for it.
At least OS X does that.
However, in the case above I'm not sure I understand your original point?
I'm not really sure anymore what anyone's point is :)
Yes, the user+ip syncing is important. But I don't see any point in adding the +ip part, since user-only syncing is just as good for most people and better for a few others.
Well, I'm not going to over-argue the point, but right now I personally have both a desktop AND a mobile device (and expect this to be a common situation for most users with a mobile device), so in my case I prefer to have the mobile device talking as little as possible, and to distinguish the two devices we probably need to use something like IP as a proxy (not perfect of course because both could be behind the same NAT...)
But even if you distinguish them, how would you treat them differently? Are you thinking about using different imap_idle_notify_interval values? But how would Dovecot know what type of device is there? I guess if you hard code some IP ranges as "mobile" that could work. But even in that case it doesn't make a difference that the syncing is done only per-user.
P.S. I posted some notes on zlib some time back - what kind of things could I do to increase the chance you might investigate supporting the COMPRESS extension in the near future? Obviously writing the code would be one option -
The only option for now.. Implementing it myself isn't really a priority.
would you perhaps mind pointing me towards the obvious spots to look at to do such an integration? I'm quite keen to give it a whirl because the Profimail guys very kindly implemented it recently and I'm hoping to see the new Thunderbird released sometime (in the next few years?) soon...!
The important part is to get zlib istream and ostreams implemented. The easiest part is to start with is by converting current zlib plugin from using gz*() functions reading files to reading the input from istream and converting it internally then in memory. So basically change it to work with:
struct istream *i_stream_create_zlib(struct istream *input);
There are several istream*.c files implementing various filters already, as well as the istream-zlib.c itself. It probably wouldn't be too difficult to do it.
For ostreams there aren't much examples. Dovecot v2.0 code tree has ostream-buffer.c. Also a month or so ago I implemented ssl-iostreams but decided not to commit them to 2.0 tree, at least not yet. I put them now to http://hg.dovecot.org/dovecot-2.0-sslstream/
Actually, here's the original Nokia paper - just reading it now, seems quite interesting:
Ed W wrote:
Actually, here's the original Nokia paper - just reading it now, seems quite interesting:
Contrary to the results in the nokia paper I find a few "low quality" results from users who used the nokia battery monitor app to show that an IDLEing wifi connection burns much more battery than a 3G connection... The punchline either way you slice it is to reduce the amount of time you wakeup the radio module, batch stuff up.
I need to go and grab my N95 and play with the voip stuff again - I wonder if I can easily double the battery life just by raising the re-register interval...
Ed W
On 14.10.2009 2:30, Ed W wrote:
Actually, here's the original Nokia paper - just reading it now, seems quite interesting:
I wonder whats difference between WM phones which connects to Exchange servers using same TCP socket via HTTP(S) and push messages while doing seems fine for battery life.
Nikolay Shopik wrote:
On 14.10.2009 2:30, Ed W wrote:
Actually, here's the original Nokia paper - just reading it now, seems quite interesting:
I wonder whats difference between WM phones which connects to Exchange servers using same TCP socket via HTTP(S) and push messages while doing seems fine for battery life.
I'm not sure I understand the question, but bear in mind that WM phones are usually massively hungry for power even at idle and usually have fairly short battery lives (and big batteries) and so the *incremental* cost of using the network may be much less apparent in that case?
Note how the author finds that his radio card consumes something like 33mA at idle, compared with his notes that other authors measure 200-400mA from various WM device radios - he notes something about perhaps there being some more research needed on choose a good radio card...
Actually for those not reading the news, CE6.5 is getting panned in reviews right now, MS have fumbled this "Sidekick"/Danger device thing big time (spent half a billion dollars buying the company and then lost all the data and likely all the customers in one day...) and it looks like their ipod killer (Pink?) is stillborn and they are getting beaten up for effectively spending the money twice building a phone + a zune when both basically do similar things. Looks like WM devices may get passed over quite a bit until CE7 is released in a blaze of glory... Oh also in the news this month is that the LSE is to move away from it's Microsoft .Net platform, plus a slew of massive bug fixes for all their platforms. All in all a tough month for MS, but to their credit they seem to have avoided many of them making the major news channels apart from the fairly anti-MS end of the geek press...
Ed W
participants (7)
-
Charles Marcus
-
Ed W
-
Nikolay Shopik
-
Odhiambo Washington
-
Pascal Volk
-
Patrick Ben Koetter
-
Timo Sirainen