From sm5ncz%[email protected] Thu Apr 30 20:42:22 1992
Received: from sm5sxl.ampr.org by sm5sxl.ampr.org with SMTP
       id AA201 ; Thu, 30 Apr 92 20:42:19 CET
Received: from sm5ncz.bbs by sm5sxl.ampr.org with BBSFWD
       id AA198 ; Thu, 30 Apr 92 20:08:59 CET
Date: Thu, 30 Apr 92 20:08:59 CET
Message-Id: <[email protected]>
From: sm5ncz%[email protected]
To: sm5sxl
Subject: fwdpr141
X-BBS-Msg-Type: P

Date: Thu, 30 Apr 92 18:39:11 CET
Message-Id: <[email protected]>
From: [email protected] (Björn Karlsson, Vikbolandet.JO88FH.E.SWE.EU)
Reply-To: [email protected]
To: sm5sxl@sm5sxl
Subject: fwdpr141
X-Mailer: User Agent V1.3
X-BBS-Msg-Type: P

   CONNECTIONLESS MAIL PROTOCOL AND MORE

  1Table of contents

  1.        General                                             2

  2.        UI Frame Connectionless Mail Protocol
  6Specification Version 1.00                          3

  3.        A Sample Conversation                               6

  4.        Problems and comments                               8



  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   1(8)
  CONNECTIONLESS MAIL PROTOCOL AND MORE


  1.        General

  1It seems to me that the main use of our network is for the
  1transfer of items of general interest (bulletins), first,
  1and personal mail, second. Now this may seem a bit strange
  1particularly when one could put a reasonable case that there
  1are more personal messages generated than bulletins (I do
  1not go along with this, but am willing to be convinced). The
  1trouble is that personal mail has an origin and one
  1destination, bulletins have an origin by N destinations
  1where N is at least every PBBS in the country!

  1The majority of traffic is the sending of bulletins to every
  1PBBS, ie, over and over again. This leads people, who think
  1in terms of telephone lines, to say we must rationalize, we
  1must stratify, more channels, more bands, etc. Can you not
  1see the beauty of one channel with many stations listening,
  1in other words, use the broadcast nature of our medium. Why
  1must we always think in terms of telephone lines? We are not
  1on the telephone, we are not in a one-to-one,
  1origin-to-destination situation. We can broadcast. Think
  1about it.

  1Anyway, after a year or so saying I really must do something
  1about it and writing the specification outlined below, I
  1have also started writing a simple terminal
  1program/conferencing system/PMS/PBBS (I haven't quite worked
  1out what it will be yet). One of this program's features is
  1that it listens to the channel and tries to generate
  1messages out of the many copies of a bulletin that are sent.
  1It turns out that it receives between 50 and 90% of all the
  1messages that pass by it on any particular pass through
  1depending on who is sending what to whom locally. This means
  1that there are four local sub-PBBSs and also the original
  1feeds to our local NTS station that I can get 95% or more of
  1my bulletins directly from without actually being connected
  1at any time.


  1I must say at this point that I don't necessarily believe
  1that we need only one channel. Trunking should occur
  1elsewhere, but I do believe that we should start thinking
  1about what we are using, its nature and use the properties
  1of our medium to the full. I also say that it may be that we
  1could use far less equipment to achieve our goals if we do
  1not go down the "professional's route." One could also ask
  1what would be the point of emulating a known solution? I
  1thought we were in this hobby to invent new and better ways
  1and means. Why else are we tolerated in the busiest and most
  1commercially valuable portions of the spectrum?

  1What I have done so far, which is merely some fancy pattern
  1matching on monitored BPQ data, is not perfect. It gets it
  1right 99.98% of the time and, as such, is not suitable other
  1than for a leaf PBBS or PMS system. I have designed a UI



  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   2
  CONNECTIONLESS MAIL PROTOCOL AND MORE


  1protocol which could give 100% data integrity while still
  1retaining the flavor of the broadcasting mechanism. I
  1outline it below.


  2.        UI Frame Connectionless Mail Protocol Specification Version 1.00

  1The aim of this protocol is to utilize the broadcast nature
  1of the radio medium to minimize the amount of air time it
  1seems to take to distribute the mail. This system is not
  1meant to replace all of the current system of connections
  1from one mailbox to another, but to optimize the
  1distribution in a local area within range of a powerful node
  1or other powerful repeating transmitter.

  1This specification is based on earlier work of mine and
  1G8UFQ (now, sadly, deceased).

  1The basis on which this protocol is devised is as follows:

  11. Radio is a broadcast medium, a packet (particularly if it
  4is sent by a powerful and/or well sited transmitter) can
  4potentially be heard by a large number of receivers.

  12. The nature of the TNC, FM radio and CSMA environment is
  4such that if a station can be heard loudly, then all
  4other stations will tend to shut up until a suitable
  4pause appears, at which point, they all tend to jump in.

  13. The loudest station usually controls the flow traffic in
  4a given area, thus any other station that uses that loud
  4station usually gets more traffic through more quickly
  4than if they go direct while the loud station is
  4transmitting.

  14. If we sent UI framed packets via the loudest station,
  4they will be heard by many people (witness all the
  4complaints about long beacon texts via several
  4repeaters). If those packets can be uniquely identified
  4as part of a particular message and also which part, then
  4a basis of a simple connectionless mail protocol exists
  4that more fully uses the broadcast nature of radio as
  4outlined in (1) above.

  15. The concept of acknowledging each packet correctly
  4received is, I believe, inappropriate for a congested FM
  4CSMA channel such as the ones we are using. Research has
  4shown (ZMODEM protocol) that it is more efficient to say
  4what you have not received. Further, because we are
  4sending bulletins which are by their nature to be
  4broadcasted, if the stations listening send their
  4requests for the bits they missed, there will be overlaps
  4such that any requests trampled on could be issued by
  4another station anyway.

  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   3
  CONNECTIONLESS MAIL PROTOCOL AND MORE

  16. A bulletin is broadcast. This protocol is a means of
  4broadcasting; the data therefore fits the protocol more
  4nearly than the current method being employed. Individual
  4mail probably fits the existing model quite well and
  4would therefore continue to use the current system as
  4would normal station-to-station conversation.

  17. I believe it to be more efficient, overall, to send a
  4complete message via a strong station and then wait for
  4requests for retries of individual parts. In other words,
  4to have a window size of infinity (or the size of the
  4message). Further, because of the long delays between the
  4TNC noticing a clear channel and the transmission
  4actually being heard at full power, it will probably be
  4necessary to send the first packet of a string twice or
  4maybe three times because of the likelihood of its being
  4trampled on by other stations [the main reason why the
  4AX.25 fixed window size of >1 has been shown to be worse
  4than simple window sizes of 1 (KA9Q)]. I propose to
  4overcome this problem by using selective reject rather
  4than the current system of `start again from the
  4beginning even though I did in fact hear your last three
  4of that window of four. This will be used in the style
  4of the ZMODEM protocol detailed in (5) above. Because we
  4will probably be repeating, we will need to send packets
  4at reasonable intervals (say 0.5 seconds) in order for
  4the repeater to receive and onward transmit it, this
  4parameter must be tunable to allow for local conditions.

  1Some Details

  1AX.25 allows up to seven packets to sent at a time in one
  1gobbit of packets. Therefore, it will be necessary to send a
  1gobbit of 1 to 7 packets, possibly with the first one
  1repeated as it almost certainly will not be heard on a busy
  1channel. Experiments will have to be conducted to find the
  1optimum number of packets to send in a gobbit, taking into
  1account direct broadcast or via a repeater.

  1Each packet should contain the following info:

  1o 1-byte Signature (suggest "~") to indicate to the software
  3that this packet may be of interest

  1o 1-byte Flag to determine the type of packet.
  3M for mail
  3H for the mail header (from, to, subject, etc)
  3E for end of message
  3R for repeat request
  3A for I am active request (could cause mail to be sent to you)

  1o 14-byte BID. A standard bid, eg, 12345_GB7TLH, some unique
  3message ID, all messages (even mail) has some implicit bid
  3of this form, but it need not be like that above. Anything
  3unique would do. Left justified, excess padded with
  3spaces.

  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   4
  CONNECTIONLESS MAIL PROTOCOL AND MORE


  1o 5-byte Offset. The offset of this packet within this
  3message. This is used differently in types H and E.

  1o 200-byte Data. This, of course, contains the data.

  1CONNECTIONLESS MAIL PROTOCOL AND MORE  - Continued

  1Contents of Data Portion

  1H - It is suggested that this is of fairly standard form,
  5ie, SB ALL @ GBR < G1TLH xxxxxxxxxxxxxxxxxxxxxxxx where
  5the offset in the header is the size of the message and
  5xxxxxxx is the title. All portions contain the BID.

  1M - The actual data portion of the message split up into
  5200-byte chunks. The offset incrementing 200 bytes (or
  5whatever) for each packet. The length of the message
  5and, thus, that of the last packet is arbitrary.

  1E - Indicates end of message. It has the length of the
  5message in the offset position. It may be useful to have
  5a CRC16 checksum in hex (4 bytes) in the data portion
  5(then again it is probably overkill).

  1R - Request for more data, in the form address/length. These
  5are free format pairs (starting with the offset position
  5as the first address), eg, 000128/200, 600/200,
  51200/400. Each pair is separated by a comma and the last
  5one is followed by a full stop (which could be left
  5out).

  1A -This is sent by a THL style box when switched on to say
  4here I am, anything interesting?

  1Addressing Issues

  1The unproto mail address needs some definition. In order to
  1recognize a packet coming in as being relevant, it must pass
  1certain tests.

  11. It must be a UI frame.

  12. It must contain the signature character `~ in the first
  4byte of the information part of the frame.

  13. The mail broadcasts need to be identified as such and so
  4an unproto address of $$MAIL is suggested. Replies could
  4contain this address for general work, but if a
  4significant number of packets with a particular
  4originating call sign are received, it is better to use
  4an unproto address of that originating call sign such
  4that only that station replies to requests for more data.
  4This should go some way to preventing race conditions
  4when two or more originating stations have the same BID
  4and start replying.


  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   5
  CONNECTIONLESS MAIL PROTOCOL AND MORE


  1The receiving station will need to be discriminating about
  1who it uses to poll for requests and, if it gets packets
  1from other stations with the required information, it must
  1discard them, but possibly remember the call signs in case
  1of failure with the original station.


  3.        A Sample Conversation

  1GB7TLH>NP2>$$MAIL <UI C>:
  1~H12345_GB7VLS 01200SB ALL @ GBR < G9ABC FRED BOGGS IS LICENSED

  1No reply - wait say 5-7 seconds

  1GB7TLH>NP2>$$MAIL <UI C>:
  1~H12345_GB7VLS 01200SB ALL @ GBR < G9ABC FRED BOGGS IS LICENSED

  1No reply - wait say 5-7 seconds

  1GB7TLH>NP2>$$MAIL <UI C>:

  1~H12345_GB7VLS 01200SB ALL @ GBR < G9ABC FRED BOGGS IS LICENSED

  1This is repeated 3 to 5 times

  1G4RQN>GB7TLH <UI C>
  1~R12345_GB7VLS 00000/1200

  1This indicates that you wish the whole lot to be sent. This
  1may be sent three times at one-second intervals, but could
  1perhaps be sent up to 10 times as it constitutes `retries.

  1I also may receive

  1GB7RWN>NP2>GB7TLH <UI C>:
  1~R12345_GB7VLS 00000/1200

  1and

  1GB7LDI>NP2>GB7TLH
  1~R12345_GB7VLS 00000/1200

  1So I send

  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00000xxxxxxxxyyyyyyyy etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00200aaaabbbbbbccccccdddd etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00400eeeeeeeeffffffffggggg etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00600hhhhhhhhiiiiiiiijjjjjj etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00800kkkkkkkkllllllllmmmmmm etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 01000nnnnnnnnooooooppppppp etc etc

  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   6
  af
   CONNECTIONLESS MAIL PROTOCOL AND MORE


  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 01200qqqqqqqqrrrrrrsssssss etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~E12345_GB7VLS 01200

  1I then might receive

  1G4RQN>GB7TLH <UI C>
  1~R12345_GB7VLS 00400/200,1000/200
  1GB7RWN>NP2>GB7TLH> <UI C>
  1~H12345_GB7VLS 00200/400
  1GB7LDI>NP2>GB7TLH <UI C>
  1~H12345_GB7VLS 00000/0,1000/200

  1This means that the need to resend packets 200, 400 and 100
  1and also 00000/0 is special. The station either has not
  1heard the header or has woken up in the middle of this
  1exchange and wants to catch up. 00000/0 will cause resending
  1the header packet. It may be worth sending it at the start
  1of an exchange in the first transmission of the message as a
  1`noise' packet that causes the channel to be `grabbed' for
  1this exchange.


  1So I send

  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00000xxxxxxxxyyyyyyyy etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00200aaaabbbbbbccccccdddd etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00400eeeeeeeeffffffffggggg etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 01000nnnnnnnnooooooppppppp etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1GB7TLH>NP2>$$MAIL <UI C>:
  1~H12345_GB7VLS 01200SB ALL @ GBR < G9ABC FRED BOGGS IS LICENSED

  1As you will note, these need not be in any particular order,
  1thus, should be slotted in the appropriate place.

  1I may then receive

  1G4RQN>GB7TLH <UI C>
  1~R12345_GB7VLS 00400/200,1000/200

  1Because there is only one packet to be sent, I send it twice
  1to make sure.

  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00400eeeeeeeeffffffffggggg etc etc
  1GB7TLH>NP2>$$MAIL <UI C>
  1~H12345_GB7VLS 00400eeeeeeeeffffffffggggg etc etc


  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   7
  af
   CONNECTIONLESS MAIL PROTOCOL AND MORE


  1I now wait 5 to 7 seconds to see if there are any more. If
  1not, I continue with the next one or shut up if there are no
  1more.


  4.        Problems and comments

  1Now there is a potential problem here in that I might
  1receive a delayed request for a packet from the previous
  1message. Two strategies might be used to cope with this.
  1Either note the request and ignore it for the time being or
  1keep the previous message file open and satisfy the request
  1among the rest of the current message. If the first method
  1is used, the current message is run out and the packet(s)
  1from the previous message are then sent.

  1The reader will note that now three stations have obtained
  1the six packet bulletin at a cost of 11 information packets
  1from the originating station including retries. The actual
  1level of retries is probably optimistic, but even on a dead,
  1quiet channel, you would require 18 packets to be sent to do
  1the same job without retries.

  1I think it likely that each originating station will have a
  1list of people it is prepared to satisfy requests from to
  1cope with lift conditions, but it may be possible to have a
  1two-tier system in which a distant or unknown station can
  1receive service, but only if a reasonable number of packets
  1seem to be getting through, eg, locals may be allowed 10
  1retries but unknown stations only 3. After all, if
  1conditions are that good they should be utilized.

  1This is preliminary, any comments, suggestions, etc would be
  1gratefully received.


  by Derek Koopman, G1TLH
  from Connect International via Hank Greeb, N8XX             page   8

 Message handled by User Agent v1.1 in SMTP-FWD

You are viewing proxied material from bitreich.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.