Re: SMTP slow???

[carl@xxxxxxxxx (Carl Hage)]

rsedc@urgento.gse.rmit.EDU.AU (David Chia) writes:
: > Actually, my studing of HTTP (sniffer traces and the like) has shown me a
: > model for using HTTP for "direct control".  This involves doing the client
: > thing directly (unless the browser has good APIs).  The server as is, even
: > the CERN server has what it takes to run the translator.
: 
: The industry trend is that the off-the-shelf web browser will become
: the universal front end across all OS's and HW platforms to many if not
: all applications such as DBMS, email reader, etc. The
: EDI-translator/server can be such application which can also
: communicate directly (as client) to the TP's http server.

Using HTTP this way might make sense as a means of integrating manually
accessed information, e.g  browsing a catalog and filling out an
order form, then when the order is complete an X12 Invoice could be
downloaded.

However, HTTP in general is not a good protocol for EDI since it is a
"pull" type of access, i.e. the client must connect with a server, query
to see if there is a transaction, and then download and/or upload an X12
message. In contrast, SMTP is a "push" type of access, where the sender
delivers a message to the recipient on demand.

OK, so you say, both TPs could operate HTTP servers. In this case,
HTTP only adds overhead to the protocol, and a simple SSL socket would
suffice and be much easier to implement. Likewise, both TPs could operate
SMTP daemons, which accept incoming messages via many alternative
networks (including store and forward) and deliver the contents to
an application.

HTTP clients and servers simply fetch a document given a URL, or post a
document at a specified URL. Clients simply return "failed" if a problem
occurs.

SMTP servers do just what EDI users need (for low level transport). They
accept incoming messages, analyze the headers, then forward the message,
deliver the message to a mailbox, or pass the message to an application
program for processing. Some message logging and receipt generation is
also possible. For outgoing messages, the SMTP daemon automatically
queues and retries the transmissions at alternate sites or alternate
times if the recipient or forwarder is not accessable.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086