Text 349, 589 rader
Skriven 2005-05-30 21:41:13 av Michiel Broek (2:280/2802)
Ärende: FSP-1018 rev 2 part 3
=============================
We define here a FIFO queue called "TheQueue", which is used to
pass incoming M_GET / M_GOT / M_SKIP frames from Receive Routine to
Transmit Routine. Receive routine itself does not react to these
frames.
Table 4: Receive Routine
+-----------------------------------------------------------------+
|RxState |Predicate(s) |Condition(s) |Actions(s)|Next |Return |
|--------+-------------+-------------+----------+--------+--------|
|RxWaitF |Get a frame |Haven't got a|none |RxWaitF |OK |
| |from Input |complete | | | |
| |Buffer |frame yet | | | |
| | |-------------+----------+--------+--------|
| | |Got Data |ignore |RxWaitF |OK |
| | |frame | | | |
| | |-------------+----------+--------+--------|
| | |Got M_ERR |Report |RxDone |Failure |
| | | |Error | | |
| | |-------------+----------+--------+--------|
| | |Got M_GET / |Add frame |RxWaitF |OK |
| | |M_GOT / |to The | | |
| | |M_SKIP |Queue | | |
| | |-------------+----------+--------+--------|
| | |Got M_NUL |Log/parse/|RxWaitF |OK |
| | | |ignore | | |
| | |-------------+----------+--------+--------|
| | |Got M_EOB |Report End|RxEOB |OK |
| | | |of Batch | | |
| | |-------------+----------+--------+--------|
| | |Got M_FILE |none |RxAccF |continue|
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | | |frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxWaitF |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxAccF |Decide how to|Accept from |Report |RxReceD |OK |
| |accept |beginning |receiving | | |
| |Incoming File| |file | | |
| | |-------------+----------+--------+--------|
| | |Accept from |Send M_GET|RxReceD |OK |
| | |offset (we do|Report | | |
| | |already have |receiving | | |
| | |a part of |file, | | |
| | |file) |requested | | |
| | | |offest | | |
| | |-------------+----------+--------+--------|
| | |Accept later |Send |RxWaitF |OK |
| | |(or failed to|M_SKIP | | |
| | |create file) |Report we | | |
| | | |will | | |
| | | |accept | | |
| | | |file | | |
| | | |later, not| | |
| | | |in current| | |
| | | |session | | |
| | |-------------+----------+--------+--------|
| | |Refuse |Send M_GOT|RxWaitF |OK |
| | |(delete on |Report we | | |
| | |remote) |do not | | |
| | | |accept | | |
| | | |file | | |
|--------+-------------+-------------+----------+--------+--------|
|RxReceD |Get a frame |Didn't got a |none |RxReceD |OK |
| |from Input |complete | | | |
| |Buffer |frame yet | | | |
| | |-------------+----------+--------+--------|
| | |Got Data |none |RxWriteD|continue|
| | |frame | | | |
| | |-------------+----------+--------+--------|
| | |Got M_ERR |Report |RxDone |Failure |
| | | |Error | | |
| | |-------------+----------+--------+--------|
| | |Got M_GET / |Add frame |RxReceD |OK |
| | |M_GOT / |to The | | |
| | |M_SKIP |Queue | | |
| | |-------------+----------+--------+--------|
| | |Got M_NUL |Log/parse/|RxReceD |OK |
| | | |ignore | | |
| | |-------------+----------+--------+--------|
| | |Got M_FILE |Report |RxAccF |Continue|
| | | |partially | | |
| | | |received | | |
| | | |file | | |
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | | |frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxReceD |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxWriteD|Write data to|Write Failed |Report |RxDone |Failure |
| |file | |error | | |
| | |-------------+----------+--------+--------|
| | |File Pos > |Report |RxDone |Failure |
| | |Reported |write | | |
| | | |beyond EOF| | |
| | |-------------+----------+--------+--------|
| | |File Pos = |Close File|RxWaitF |OK |
| | |Reported |Send M_GOT| | |
| | | |Report | | |
| | | |File | | |
| | | |Received | | |
| | |-------------+----------+--------+--------|
| | |File Pos < |none |RxReceD |OK |
| | |Reported | | | |
|--------+-------------+-------------+----------+--------+--------|
| |RxEOB |Get a frame |PendingFiles |none |RxDone |OK |
| | |from Input |list is empty| | | |
| | |Buffer |-------------+----------+--------+--------|
| | | |Didn't get a |none |RxEOB |OK |
| | | |complete | | | |
| | | |frame yet or | | | |
| | | |TxState is | | | |
| | | |not TxDone | | | |
| | |-------------+----------+--------+--------|
| | |Got M_ERR |Report |RxDone |Failure |
| | | |Error | | |
| | |-------------+----------+--------+--------|
| | |Got M_GET / |Add frame |RxEOB |OK |
| | |M_GOT / |to The | | |
| | |M_SKIP |Queue | | |
| | |-------------+----------+--------+--------|
| | |Got M_NUL |Log/parse/|RxEOB |OK |
| | | |ignore | | |
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | |or data frame|frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxEOB |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxDone |none |none |none |RxDone |OK |
+-----------------------------------------------------------------+
We define the list called "PendingFiles". After we put the last
byte of file into output buffer, we cannot yet consider the file as
being successfully transmitted, thus we have to add the file to
this list and then look for corresponding incoming M_GET / M_GOT /
M_SKIP frames to remove the file from the list and decide whether
the file was indeed received by remote or remote will accept this
file later, or something else. After we have sent M_EOB frame, we
must wait until PendingFiles list gets empty before disconnecting.
If the connection accidentally breaks, all the files left in
PendingFiles are considered unsent and will be re-transmitted in
the next session. If the connection breaks when the remote did
actually receive the file (but the corresponded confirmation frame
(M_GOT) didn't came back to us) and we are resending this file
again in the next session, remote may get two copies of the same
file (file dupe). Binkp allows to reduce or totally suppress such
dupes (at a cost of performance, of course), see Non-Reliable mode
and "No Dupes" protocol extension (to be found in a separate
documents).
Table 5: Transmit Routine
+-----------------------------------------------------------------+
|TxState|Predicate(s)|Condition(s) |Actions(s) |Next |Return |
|-------+------------+--------------+------------+-------+--------|
|TxGNF |Open next |File opened OK|Send M_FILE |TxTryR |continue|
| |file from | |Report | | |
| |outgoing | |sending file| | |
| |queue |--------------+------------+-------+--------|
| | |Failed to open|Report |TxDone |Failure |
| | |file |failure | | |
| | |--------------+------------+-------+--------|
| | |No more files |Send M_EOB |TxWLA |continue|
| | | |Report end | | |
| | | |of batch | | |
|-------+------------+--------------+------------+-------+--------|
|TxTryR |Check |TheQueue is |none |TxReadS|continue|
| |TheQueue |empty | | | |
| | |--------------+--------------------+--------|
| | |TheQueue is |call ProcessTheQueue|continue|
| | |not empty | | |
|-------+------------+--------------+--------------------+--------|
|TxReadS|Read data |Read failed |Report Error|TxDone |Failure |
| |block from |--------------+------------+-------+--------|
| |file |Read OK, |Send data |TxGNF |OK |
| | |Reached EOF |block frame | | |
| | | |Close | | |
| | | |current file| | |
| | | |Add current | | |
| | | |file to | | |
| | | |PendingFiles| | |
| | |--------------+------------+-------+--------|
| | |Read OK, not |Send data |TxTryR |OK |
| | |reached EOF |block frame | | |
|-------+------------+--------------+------------+-------+--------|
|TxWLA |Check |TheQueue is |none |TxDone |OK |
| |TheQueue |empty and | | | |
| | |RxState >= | | | |
| | |RxEOB | | | |
| | |--------------+------------+-------+--------|
| | |TheQueue is |none |TxWLA |OK |
| | |empty and | | | |
| | |RxState < | | | |
| | |RxEOB | | | |
| | |--------------+--------------------+--------|
| | |TheQueue is |call ProcessTheQueue|continue|
| | |not empty | | |
|-------+------------+--------------+--------------------+--------|
|TxDone |none |none |none |TxDone |OK |
+-----------------------------------------------------------------+
We define a list called KnownFiles. This list contains files that
can be requested by the remote using M_GET command. This list shall
at least contain all the files that are part of the PendingFiles
list.
| The term "finalize file" means that the file MUST be marked as sent
| in the mailer outbound queue.
Table 6: ProcessTheQueue routine
+-----------------------------------------------------------------+
| Predicate(s) | Condition(s) | Actions(s) |
|--------------------+--------------------+-----------------------|
| M_GET received | requested file is | Report unknown file |
| | not in the | |
| | KnownFiles list | |
|--------------------+--------------------+-----------------------|
| M_GET received for | Requested pos is | Close and finalize |
| a known file | FileSize | file. |
| | | Report that remote |
| | | refused file being |
| | | transmitted. |
| | | | Remove file from the |
| | | | PendingFiles list |
| | | Set TxState to TxGNF |
| |--------------------+-----------------------|
| | Requested pos is | Set file pointer to |
| | less than FileSize | requested pos. |
| | | Report that remote |
| | | requested offset. |
| | | Set TxState to TxGNF |
| |--------------------+-----------------------|
| | Requested pos is | Ignore frame |
| | greater than | |
| | FileSize | |
|--------------------+--------------------+-----------------------|
| M_GOT file that is | none | Close and finalize |
| currently | | file |
| transmitting | | Report Remote refused |
| | | file being transmitted|
| | | | Remove file from the |
| | | | PendingFiles list |
| | | Set TxState to TxGNF |
|--------------------+--------------------+-----------------------|
| M_GOT file that is | File is in | Finalize file |
| not currently | PendingFiles list | Report file has been |
| transmitting | | sent |
| | | Remove file from the |
| | | PendingFiles list |
| |--------------------+-----------------------|
| | File is not in | Ignore frame |
| | PendingFiles | |
|--------------------+--------------------+-----------------------|
| M_SKIP file that | none | Close file (do not |
| is currently | | finalize, we will |
| transmitting | | send it later, not in |
| | | current session) |
| | | Report remote will |
| | | accept this file |
| | | later |
| | | | Remove file from the |
| | | | PendingFiles list |
| | | Set TxState to TxGNF |
|--------------------+--------------------+-----------------------|
| M_SKIP file that | none | Report remote will |
| is not currently | | accept this file |
| transmitting | | later |
| | | Remove file from |
| | | PendingPiles, if |
| | | exists there |
|--------------------+--------------------+-----------------------|
| M_NUL "OPT option" | none | ignore or doing |
| or another frame | | action required by |
| indicate/contents | | protocol extension |
| protocol extension | | |
| received | | |
+-----------------------------------------------------------------+
6.3 Session Termination
-----------------------
A session may be terminated in any of the following cases:
1. If transmitted or received M_ERR. In this case, the session
should be deemed aborted due to a fatal error.
2. If transmitted or received M_BSY. In this case, the session
should be deemed aborted due to non-fatal error typically
because of temporary lack of resources to proceed with the
session.
3. If all of the following applies:
* all the files have been sent
* we have received M_EOB from the remote side (there are no
more files for us),
* we have received acknowledgements for all the files sent,
* we have received all the files re-requested by M_GET,
In this case, the session should be deemed successfully
completed.
A session termination itself is not a protocol stage. Mailer may
terminate a session at any time simply by issuing disconnect
(shutdown) command to the underlying transport layer, provided any
of the three conditions above are met. Mailer MUST take all proper
steps to provide a graceful shutdown of the transport layer, as it
is the transport layer that is responsible for all the data
transmitted by one side to be received by another before
disconnection, provided that shutdown of the transport layer
protocol was successful.
7. Protocol Identification String
---------------------------------
In session setup stage both sides send M_NUL frames like this:
M_NUL "VER mailer/version binkp/1.0"
where "mailer version" is mailer identification string, usually
mailer name and version, in free form, and "binkp/1.0" is protocol
identification string, case-insencitive. Mailer identification
string MAY have contents spaces and SHOULD only consist of
characters with ASCII codes range 32-126 (" ".."~").
Example:
M_NUL "VER binkd/0.9.5a/FreeBSD binkp/1.0"
Version identification frame SHOULD be send and may be received
before autentification ends (before sending of M_PWD frame by
the originating side and M_OK by answering side).
If no protocol identification string is received, the binkp/1.0
protocol MUST be assumed. Any mailer with a higher protocol as
binkp/1.0 that receives a binkp/1.0 version identification string
from a remote mailer, or receives no indentification string at
all, MUST fallback to the binkp/1.0 protocol.
8. Protocol Extensions
----------------------
Protocol extensions are optional and therefore not documented in
this Fidonet Technical Standard document, only the method of
showing the supported protocol extensions is shown.
Sides indicate supported protocol extensions by sending M_NUL
frame(s) with "OPT list_of_extensions" string, where
list_of_extensions is a space separated list of supported protocol
extensions. Whenever multiple M_NUL "OPT ..." frames are received
during the session, they SHOULD augment the current list of
extensions rather than replace it, unless specifically stated
otherwise for a particular option.
Mailer SHOULD NOT use any extension unless exactly sure that this
extension is supported by the remote. Mailer SHOULD use M_NUL "OPT
..." to indicate supported options. Other methods for indicating
supported extensions are allowed as long as they provide full
backwards compatibility.
8.1 Recommended protocol extensions
-----------------------------------
At the time of writing this document the following protocol
extensions are recommended:
* None-reliable mode (NR).
* Challenge-Response Authentication Mechanism (CRAM).
Other documents may be released after this document. See the actual
list of FTSC documents.
9. Binkp license.
-----------------
To implement the binkp/1.0 protocol pay attention to the following
notes:
1. The protocol shall be referenced to as binkp and not in any
other way. You should also include the author name (Dima
Maloff) of the binkp protocol in your copyright statement
for the software.
2. Binkp shall always be backwards compatible with it's previous
versions. Binkp allows development of the new capabilities
without compromising interoperability with previous versions.
Therefore, it is important that future developments of the
protocol are not pursued in different directions by different
people. If you have any suggestions regarding future
developments of the protocol, make a reasonable effort to
contact the author(s), so that the development efforts can
coordinated in a way advantageous for everybody.
3. If your implementation is not compatible with past, present or
future binkp specifications, you shall reference to it as a
"binkp variation" or "binkp derived".
Binkp author: Dima Maloff.
10. Glossary
------------
Many entries in this glossary are provided courtesy of Butterfly
Glossary of Internet and Data Communication terms and RFC-1983.
connection-oriented
Data communication method in which communication proceeds
through three well-defined phases: connection
establishment, data transfer, connection release. TCP is a
connection-oriented protocol.
data link layer
The OSI layer that is responsible for data transfer across
a single physical connection, or series of bridged
connections, between two Network entities.
flow control
A technique for ensuring that a transmitting entity does
not overwhelm a receiving entity.
HDLC
(High level Data Link Control). Popular ISO standard
bit-oriented, data link layer protocol derived from SDLC.
HDLC specifies an encapsulated method of data on
synchronous serial data links.
IP
(Internet Protocol). The Internet Protocol, defined in STD
5, RFC 791, is the network layer for the TCP/IP Protocol
Suite. It is a connectionless, best-effort packet switching
protocol.
network layer
Layer 3 of the OSI reference model. Layer 3 is the layer at
which routing, addressing and connection management take
place.
OSI (Open Systems Interconnection) Reference Model
A seven-layer structure designed to describe computer
network architectures and the way that data passes through
them. This model was developed by the ISO (International
Organization for Standardization) in 1978 to clearly define
the interfaces in multivendor networks, and to provide
users of those networks with conceptual guidelines in the
construction of such networks.
port
A port is a transport layer demultiplexing value. Each
application has a unique port identifier associated with
it.
physical layer
The OSI layer that provides the means to activate and use
physical connections for bit transmission. In plain terms,
the Physical Layer provides the procedures for transferring
a single bit across a Physical Media.
Quality of Service
(Also QoS). A measure of performance for a transmission
system that reflects its transmission quality and
availability of service.
reliable transmission
a type of transport service that:
* recovers from errors by retransmitting errored frames
* delivers frames in correct sequence (also known as
stream-oriented)
* usually is used in connection-oriented mode
session layer
Layer 5 of the OSI reference model. Coordinates session
activity between applications, including application-layer
error control, dialog control, and remote procedure calls.
sliding window flow control
Method of flow control in which a receiver gives
transmitter permission to transmit data until a window is
full. When the window is full, the transmitter must stop
transmitting until the receiver advertises a larger window.
socket
Software structure operating as a communications and point
within a network device.
TCP
Transmission Control Protocol. An Internet Standard
transport layer reliable protocol defined in STD 7, RFC
793. It is connection-oriented and stream-oriented.
TCP/IP protocol suite
Transmission Control Protocol over Internet Protocol. This
is a common shorthand which refers to the suite of
transport and application protocols which runs over IP.
transport layer
Layer 4 of the OSI reference model. The transport layer is
responsible for reliable network communication between end
nodes. It implements flow and error control and often uses
virtual circuits to ensure reliable data delivery.
unixtime
number of seconds elapsed since 00:00:00 UTC, Jan. 1, 1970.
11. References
--------------
[FTS-0001]
A Basic FidoNet(r) Technical Standard, Revision 16. Randy
Bush, Pacific Systems Group, September 30, 1995. FTS-0001.
[FTS-0006]
YOOHOO and YOOHOO/2U2. The netmail handshake used by
Opus-CBCS and other intelligent Fidonet mail handling
packages. Version 002, Vince Perriello. 30-Nov-1991.
FTS-0006.
[FSC-0039]
M.Howard, A type-2 packet extension proposal, FSC-0039
Version 4, 29-Sep-1990. FSC-0039.
[FSC-0045]
T.Henderson, Proposed new packet header, Version 1,
17-Apr-1990. FSC-0045.
[FSC-0048]
J.Vroonhof, Proposed type-2 packet extension, Version 2,
21-Oct-1990. FSC-0048.
[FSC-0081]
M.Staldal, A type-3 packet proposal, Version 1,
01-Mar-1995. FSC-0081.
[EMSI]
Joaquim H. Homrighausen, EMSI/IEMSI protocol definition.
May 3, 1991. FSC-0056.
[FTA-1006]
Key words to indicate requirement levels, Fidonet Technical
Standards Committee administrative. FTA-1006.
[UTF8]
UTF-8, a transformation format of ISO 10646. F. Yergeau.
January 1998, RFC 2279.
[ISO10646]
ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set
(UCS) -- Part 1: Architecture and Basic Multilingual Plane.
Five amendments and a technical corrigendum have been
published up to now. UTF-8 is described in Annex R,
published as Amendment 2.
[FSP-1011.003]
Binkp - a protocol for transferring FidoNet mail over
reliable connections by Dima Maloff, Nick Soveiko and Maxim
Masiutin, 31 July 2000.
[FSP-1011.004 draft 8, not yet published]
Used to correct state tables an clarify some explanations.
A. History
----------
Revision.1, 20031222
First release (revised from FSP-1011 rev 3 by FTSC).
Revision.2 200401xx
Clarified some actions in ProcessTheQueue.
Added test for PendinFiles in Receive Routine RxEOB.
Greetings, Michiel Broek
Email: mbse@mbse.dds.nl
Fidonet: Michiel Broek at 2:280/2802
... If money can't buy happiness, I guess you'll just have to rent it.
--- MBSE BBS v0.71.2 (GNU/Linux-i386)
* Origin: MBSE Linux BBS. Made in the Netherlands (2:280/2802)
|