The role of transfer protocols

David,

On 1/5/06, David Hull <dmh@tibco.com> wrote:
>  OK, so here are the constraints:
>
>
> I want to send a message to some intermittently connected device.
> I would like acknowledgment when the message finally arrives.
> This acknowledgment needs to be asynchronous.  I cannot keep a connection
> open until the destination device decides to come back on line.

Sounds good.

>  Questions:
>
>
> What transfer protocol would you suggest for this?  HTTP, SMTP, FTP etc.
> clearly don't solve this problem and aren't intended to.

Not so!  Transfer protocols are, in general, designed to solve exactly
those kinds of problems; how to exchange documents between
applications distributed over a network.

There's obviously no "uber" transfer protocol that is appropriate for
all data transfer scenarios, but some are useful for a wider variety
of tasks than others.  I consider HTTP to be the most generally useful
transfer protocol that exists.

> What problems do you see in building a solution on top of *TP?  Specifically
>
> Use <your favorite transfer protocol> to put the message into a buffer
> somewhere.  It would be polite for the transfer protocol to acknowledge that
> the message was received and queued, but it's not strictly necessary.

HTTP and SMTP are well suited to that scenario, and both provide acks
with queue-like semantics; HTTP 202 and SMTP 250 (the latter's
queue-like-ness being by virtue of SMTP response semantics being
hop-by-hop).

FTP would require more coordination than HTTP or SMTP, as it doesn't
include a "data submission" semantic, only a "data storage" semantic. 
Therefore, the client and server have to coordinate the names of
stored documents out-of-band so as to approximate the data submission
semantic.  In fact, Infospace used to use (and maybe still does,
dunno) exactly this interface for their third party mobile content
interface back in 2001; they published naming conventions for file and
directory names for content providers to use.  But with such a
convention, an FTP server could be used as a queue.

> When it's on line and in the mood to retrieve messages, the destination
> device uses <some transfer protocol it likes> to pull messages out of the
> buffer.

If you have a specific "pull" requirement, then you could use HTTP,
IMAP, FTP, POP, ...  SMTP is obviously "push"-only.

> Either the destination device or the buffer uses <a suitable transfer
> protocol> to send me an acknowledgment when this happens. This seems quite a
> bit like using return receipt with email.  Notably, doing so works
> regardless of whether I'm using raw UUCP, SMTP, POP, IMAP or a carrier
> pigeon with a USB drive to get email.  The same concept even works with
> snail mail (no surprise).

POP wouldn't work; it's pull-only.  But sure, for some simple
scenarios like that one, a lot of transfer protocols would fit the
bill.  As the scenario gets more complex though, the differences
between the capabilities of the protocols becomes more apparent, as
hopefully described above.

Mark
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Friday, 6 January 2006 15:32:44 UTC