* Crossposted in NET_DEV
* Crossposted in FTSC_PUBLIC
* Crossposted in ENET.SYSOP

Hello All!


Under some circumstances the known Fido transfer protocols as FTS-1, Yoohoo
and EMSI are no longer appropriate.

I have written a new protocol, which reduces cost for a special sort of
polls by about 70 % already with its first (and bad) implementation, and
allowes to use non-gratis dial-up-lines to be used as if they were leased
lines.


Now it is still early enough to change the protocol, so I want to give you
the chance to make some useful comments how to change it.


But first of all: under which circumstances is the new protocol (which I
named X76) useful, and why do we need that?


I have several links with not very much traffic. Nearly all of them use
ISDN/X75, so there are no modem handshake times. Let's take a link with 400
kB daily traffic, which is a transfer time of 50 s daily.

With one poll daily, that is a transfer time of 50 s and around 9 s
EMSI-handshake and some other handshakes, together 59 s at around 0.001
USD/s, 0.059 USD cost per day. (With german phone costs _since_ 1998.)

With 50 polls of 8 kB each this is 50 times 1 second transfer time and 9 s
EMSI-handshake, together 50 s transfer and 450 s handshake time, 500 s a
day, 0.50 USD cost per day.

You see: with X75 (no modem connection/handshake times) and phone costs
that bill only the seconds you are connected, you need to eliminate the
EMSI-handshake in order to be able to have frequent polls for the same
price as one poll per day.

In fact after elimination of handshake times you can crash everything
immediately to your link partner, without having to pay anything more; so
you can use your dialup lines as if they were leased lines.

But whatever I did, I could not eliminate EMSI handshake time or reduce it
below 7 s for an empty poll. It seems with X75 we need several hundred
milliseconds (around 0.5 s) until a data packet has moved from mailer
through cFos, through CAPI, ISDN-adapter, phone line, ISDN-adapter, CAPI,
cFos, mailer und is answered. So when there are several packets that must
be answered in the beginning of the session, and every answer takes 0.5 s,
we waste around 5 s or more.

So what we need is a transfer protocol that eliminated these
question-and-answer-games. Whoever has something to send, should dial the
other one, and after the connect is done, the sender should immediately
send all his data _in one block only_ without the need to wait for answers
inbetween. When everything is sent, the sender should only wait for a
little "OK" from the reciever and then disconnect immediately. 1
block to send, 1 block to recieve, no other time losses, no questions, no
answers exept the final "ok".


This seems to be impossible with other Fidonet transfer protocols, so I
invented a new one that I called X76 (since it is useful for
X75-connections with 1-s-units to pay for... does somebody have a better
name?).

Here is the protocol itself:


=== Cut ===
                Offset     Length
   Sender:
       Header Part:
                     0          8     'X76 1.00'
                     8          8     Total length N of Data Part
                    16          4     CRC-32 of Data Part
                    20          4     reserved (should be 0)
                    24          8     ODP: offset of Data Part (usually 32)

       Data Part:  ODP          N     N Bytes of Data


(ODP allowes future extensions of the header part. Header and data part are
sent immediately after the connect.)


   Reciever:
       Keeps quiet until everything is recieved, then it returnes

                Offset     Length

                     0          1     76 ('L')
                     1          1      0 (result code... 0: ok)
                     2          2      0 (reserved)
                     4          4     CRC-32 of recieved Data Part

If anything unexpected happens, sender and reciever should disconnect
immediately. The reciever may answer with a non-zero result code instead.

=== Cut ===

The reciever has at least to be able to interprete the data part as a
single ZIP file. All the files, file date/times, passworts etc. may be
contained in this single ZIP file. There is no negotiation of these things.


A (very poor and not optimized) implementation based on T-Mail/2 2.604 is
tested since a few days. It reduced the connection times of short polls
from around 8-10 s to 2 s. This allowes me to send every mail that arrives
here for the link directly to the reciever.

An optimized implementation directly implemented into the mailer instead of
using scripts and external executables might further reduce connection time
to less than a second for a small mail of 2 kB.


Comments?


I am not an experienced mailer or protocol developer, of course, so maybe I
made several bugs while inventing it. So give me some better proposals...
but please something that I or somebody else will really implement. Nice
protocols in cyberspace that nobody really implements won't help anybody.


This mail and the X76-protocol definition: (C) 1998 Eckhard Mueller, Rheine

I will probably give all rights of the protocol definition to the public,
but I want to hear your comments first in order to be able to make useful
protocol changes _before_ several people implement it.


Bye

Eckhard

--- GoldED/2 2.50.Beta6+