-*- text -*-

NOTE! This is a program I wrote in February 2000. This was repackaged
in 2005 in the hope that it might be useful for someone.

M.C. Widerkrantz, mc at hack.org
2000-02-16

This is a proof of concept implementation (well, a quick hack, really)
of a suggested e-trade system. My point here is to show that there is
no need to use extensive XML libraries to implement an electronic
trade model. Instead, I use the much simpler Common Gateway Interface
and I have no need for a generic XML parsing library. This way, I get
much less code to maintain in the system.

This is a collection of Python CGI scripts that make up the functional
equivalent of a system with an Internet Payment Provider (IPP), a
seller and a consumer.

The scenario is that the seller has an online catalogue where the
consumer chooses what to buy. Both contact the IPP who handles the
transaction.

They all use HTTP connections for all transactions and most of the
communication is done in either plain text, URL encoded GETs or POSTs,
except towards the consumer browser which, of course, is done in
HTML. Since this is only a proof of concept, no encryption is used,
but it could rather easily be added.

The database used on my test system was a Berkeley DB 2.0 database,
but the code allows for use of any DBM compatible database. What is
actually used depends on your Python installation.

The bare CGI system is rather slow, taking about 0.4 seconds for a
complete transaction to complete if running on a local machine under a
native HTTP server. [1]

I think that most of the slow response time is from 1) forking off
CGIs, and, 2) creating new TCP sessions for each CGI call as well as
inter-CGI communication.

Imagine, instead the use of daemons including the code of the CGIs,
acting as their own HTTP servers. These never fork off any new
processes and does all the communication themselves. These are
included as ipp-server.py and seller-server.py, respectively.

If we use the daemon set to communicate with each other instead of the
bare CGI scripts, every transaction takes about 0.05 seconds. [2] Most
of the time is probably spent establish the many TCP connections
between them, even though some overhead, of course, comes from the use
of the Python HTTP server instead of the native HTTP server.

The many TCP connections are, of course, wasteful of time and
resources. It would be a much better idea to keep these to a minimum
where it is possible (and where it matters the most), e.g. between the
seller and the IPP.

Each seller could have a single TCP connection to the IPP and keep it
as long as possible, immedietly connecting again if (or when) the
connection goes down.

[1] I used Boa, a very simple non-forking native HTTP server. However,
it does fork when starting CGI scripts.

[2] This is the result of a test running perf.py 1000 times on the
daemon implementation:

  $ time ./perf.py
  real    0m50.042s
  user    0m0.070s
  sys     0m0.020s
  $

The connections were completely off the wire on the loopback interface
under Linux 2.2.13 on an Intel Pentium II 330 MHz CPU. I used the
Berkeley DB 2.0 database.
