Hi, Caskey and everyone.
Sorry for low list activity from me lately - I'll answer it all in time
but ehem [1], I've been reasonably busy the last few days so please bare
with me. :-)
This discussion is a bit confusing in that I'm not quite sure what we're
trying to achieve, so I'm throwing in some stuff here and hope it helps.
:-)
On Fri, 7 Mar 2003, Caskey L. Dickson wrote:
>On Friday, March 7, 2003, at 07:32 am, Charlie Brady wrote:
>> On Thu, 6 Mar 2003, Caskey L. Dickson wrote:
>>> On Thursday, March 6, 2003, at 07:04 am, Charlie Brady wrote:
>>>>> It is my implicit
>>>>> belief that an IMAP server deals with multiple simultaneous client
>>>>> connections, but multiple separate instances of itself is another
>>>>> issue.
These are actually the same thing, if I understand you correctly.
>>>> Dealing with multiple simultaneous clients pretty much implies dealing
>>>> with multiple instances of the server.
Yup.
>>> I'm drawing a distinction here between one instance of a server having
>>> multiple client connections and multiple instances of a server running,
>>> each modifying the same mail store.
These are handled similarly in Binc. When using a standard TCP wrapper,
IPC is folly so communication between instances "has to" go through the
mailstore.
"Has to" -> I think this is a good thing really, because I have enough
experience with IPC to know that it's best to avoid it where possible. :)
It _would be possible_ to share memory segments and use these for
communicating, and there are other mechanisms too, but that would be in
complete breach with my design philosophy.
>> I realise that you are making that distinction, but I am saying that it
>> isn't a useful one. Most (all?) *nix IMAP servers have a single client
>Don't forget we're talking about simultaneous modification of a mail store.
> With one instance of a server, it is required to support multiple
>simultaneous connections from clients, and in this sense, the Binc
>instance is a single MUA which is rightfully expected to manage its own
>interactions with the mail store. However, this assumption does not
>extend to multiple instances of the server, on the same or different hosts.
> The fact that each connection is most likely handled by a separate
>process is totally irrelevant. My point is this:
>* It is reasonable to assume that (and required that) an instance of Binc
>(or any IMAP server) correctly manages concurrent access to one instance
>of itself.
>* It is UNreasonable to assume that multiple instances of Binc (or any
>combination of IMAP servers) manage concurrent access to the mail store.
Multiple instances of Binc do handle concurrent access to the mail store.
You can run as many instances of Binc as you want on the same Maildir
concurrently, doing what they want when they want.
There isn't much technical documentation on Binc, but here's some: Maildir
itself can not be used with IMAP if there is no locking mechanism. Binc
creates a lock file called <mailbox>/bincimap-scan-lock whenever it does a
scan, in order to ensure that UID delegation is done safely with multiple
instances of Binc on the same mailstore.
The only reason for this lock is to ensure that if any one instance of
Binc has seen a message arrive in the mailstore, then all other instances
of Binc must also see this change.
Since all Bincs share this communication via the cache files, Binc needs
to make sure that from the depository is scanned and until the cache file
is safely written, the mailstore must be locked.
>IFF the concurrency controls implemented by Binc (or any other IMAP server)
> happen to work irrespective of instances as well as connections then the
>behavior you desire will arise, but it is not required by IMAP and more
>importantly, has non trivial implementation considerations to do so.
What's very important is that Binc doesn't care about other Maildir
clients accessing the depository. So Binc can be used safely together with
any other Maildir clients. Multiple clients don't even have to share the
same locking mechanism.
>> So in every case you need to deal with multiple instances of the daemon.
>Sorry, this is wrong. You cannot start out by saying that "most (all?)"
>and then claim that it covers every case, because it does not.
But it is true - Binc _has_ to deal with other instances in one way or
another. Specifically, the IMAP protocol does not require multiaccessed
mailboxes, but it does require consistency across multiple IMAP sessions
to the same mailbox (although not necessarily concurrently).
This means that even if two clients were not allowed to access the
depository concurrently (which they are), two clients that worked "on
shifts" would be required to have the exact same understanding of the
state of the Mailbox.
And to do that, Binc has to do some stuff that it didn't have to had this
requirement not been in place.
For instance, POP3 does not have this requirement - so multiaccessed POP3
mailboxes are much easier to deal with.
>Furthermore, Binc doesn't currently lock the mail store for structural
>modifications, and I can think of numerous ways of implementing this that
>are all correct but do not manage multiple instances. Something that is
>not required by IMAP.
True, it only locks the mailstore when scanning for changes and updating
the cache file. :-) Which in practise means when updating its state with
what changes were made to the mailstore.
Andy
[1] I lost my job and am in the process of getting a new one, so
first things have to come first. :P
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | Nil desperandum
