On Sat, 15 Jan 2000, Bruce Guenter wrote:
> On Sat, Jan 15, 2000 at 01:20:05AM -0500, Russell Nelson wrote:
> > What about asynchronous commands and
> > notifications? I'd nuke 'em, myself.
>
> Which of course begs the question about what kinds of events are really
> necessary for a mailbox access protocol. In my admitedly simplistic
> view, I can only think of a "new mail" event.
>
> > As far as I'm concerned,
> > asynchronous notifications can be performed using UDP. No reason to
> > tie up a TCP connection.
>
> Agreed, except for the unreliability of UDP.
in addition, there is no way for the sending application to know if the
receiving application is still running, or even that the same user is sat
at the same machine. Think of a student lab where one has students
rebooting machines instead of closing all applications. By the time one
has put the necessary security information into the protocol one might as
well have used TCP. OTOH using a separate TCP connection to the machine
for events coming from the server makes more sense than embedding them in
the command channel. UDP for user-level-applications has to be a carefully
made decision with more than just a simplistic approach
>
> > And even if you didn't mind doing that, then
> > events of interest could be reported using a prompt which conveyed the
> > same information as "You have a pending event". So you'd either be
> > executing a command, or else you'd be running the "wait for event"
> > command.
>
> Or polling, which the server is likely to have to do anyways to retrieve
> the events.
polling is bad, if only becuse it leads to:
- keeping a TCP connection open (network bandwidth)
- keeping a server process alive (memory, OS resources)
- delays notificiation by (polling interval)/2 in most cases
- waste resources when there is no email.
IMHO if one is going to design a new mail retreival protocol then what is
requireed is something which runs on a single TCP connection is
authenticated securely, and requires the client to register the type of
things it wants to know about then then lets the server send them at its
own rate.
> > > Asynchronous is a total botch. If you want multitasking,
> > then open up another TCP connection.
>
> This leads me to question if it would be a good idea to look at the FTP
> model of opening up a secondary channel (with the option of opening more
> than just one) that transfers exactly one message before closing,
> leaving the initial connection available for command data?
no, this is bad, one looses the adaptive flow control (slow start, etc)
which having only the one connection is worth. What is much better is
including the size explicitly of the transfer at the beginning of the
message and storing messages in network-byte order. then the receiving
application knows the next 4567 bytes (say) are the message, and doesn't
mess with it until it is written to disk. At which point it might choose
to convert it into a local mailbox format. Sending applications are
simplified and there is much less chnagce of the message being damaged in
transit.
RjL
==================================================================
You know that. I know that. But when || Austin, Texas
you talk to a monkey you have to || Email: [EMAIL PROTECTED]
grunt and wave your arms -ck ||
