SMTP slow???

[Mats Jansson <mjansson@xxxxxxxxxxx>]

I just wanted to throw in some data on how "slow" SMTP in EDI really is.  There
have been a number of postings that indicate that SMTP moves slower than a DMV
clerk on a Friday afternoon.  Granted, there are a lot of factors, mainly within
each company's range of control (mail routing etc.), but the SMTP EDI testing I
have been involved in over the last couple of months have produced the following
results:

Definition: Roundtrip = EDI message sent, and NRR received back.  This does not
include encryption and signature, but does include "decryption" of the NRR.

Average time for round trip:  47 seconds

IS THAT TOO SLOW???

The size of the transmissions in this case is very small, about 1K, so it would
be interesting to do a test with larger transactions.

In either case I argue that this kind of turnaround time opens up affordable
"near real time" EDI opportunties in many areas.  In fact, it speeds
implementations
as well, since two partners can do real time testing and map modifications
and do
in a few hours what used to take days (if not weeks) in iterations.

SMTP's store-and-forward nature is both a pro and a con, I think.  In a way,
it's
nice to not be dependent on a particular server (ftp) being accessible when the
transaction takes place.  On the other hand, you don't know if the "path" into
your partner's system is clear of debris, although the NRR helps a whole lot in
at least knowing whether they received it correctly.

In summary, I think SMTP is a highly viable alternative to traditional EDI, and
has the speed to support "near real time" applications.  I also think it is the
most practical choice for internet EDI at this time.  This doesn't mean,
however, that I dismiss ftp or http.  I'm sure there are many applications where
they make sense, and some of them will overlap with smtp, to be sure.