Text 391, 966 rader
Skriven 2005-06-29 07:02:58 av Scott Little (3:712/848)
Ärende: FRL-1006.001 RC1
========================
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FRL-1006
Revision: 1 (release candidate 1)
Title: Binkp - a protocol for transferring FidoNet mail over
reliable connections
Authors: Dima Maloff
Nick Soveiko
Maxim Masiutin
Issue Date: 8 July 2005
Review Date: N/A
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Reference Library document (FRL).
This document arises from, and obsoletes FSP-1011.003 which was not
promoted to a Fidonet standard. The reasons for this decision are
given below.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatsoever.
Adjudication
------------
The FTSC felt FSP-1011 would be better split into multiple documents
covering the core of Binkp, plus optional extensions.
Abstract
--------
This specification defines binkp - a protocol to handle a session
between two Fidonet Technology systems over a reliable connection.
Assumption that the connection is reliable makes possible to
eliminate error-checking and unnecessary synchronization steps,
achieving both ease of implementation and major performance
improvement over connections with large unpredictable delays (e.g.
Internet).
Available formats
-----------------
Binkp Specification is also available in HTML format at
http://www.ritlabs.com/binkp/
Table of contents
-----------------
1. Background
1. Objectives
2. Motivation for a New Protocol
2. Definitions
3. Protocol Overview
4. Frame Format
1. Notation
2. Examples
5. Protocol Commands and Their Arguments
1. Classification
2. File Name Issues
3. Non-ASCII Characters in Command Argument symbol string
4. Binkp Commands
5. Example of Frame Exchange in a Simple binkp Session
6. Protocol States
1. Session Setup Stage
1. Originating Side
2. Answering Side
2. File Transfer Stage
3. Session Termination
7. Recommended Protocol Extensions
1. Non-Reliable Mode
2. Multiple Batch Mode
3. Multiple Passwords Mode
4. Keyed Hashing Challenge-Response Authentication Mechanism
1. Overview
2. Sequence of Steps
3. Generating and Transmitting Challenge Data
4. Producing and Transmitting a Digest
5. Indicating CRAM Capabilities
6. Example of Frame Exchange During CRAM Authentication
7. Notes on Hash Function Algorithms
8. License
9. Glossary
10. References
11. Acknowledgements
A. Author Contact Data
B. History
---------------------------------------------------------------
1. Background
-------------
1.1 Objectives
--------------
It's been a long time since a new Fidonet protocol has been
developed, [EMSI] definitions being published last time in 1991,
not speaking about basic standards, [FTS-0001] and [FTS-0006].
Fidonet is evolving everyday and new transport layers are being
introduced into practice. This led to a situation when in certain
Fidonet Regions a visible portion of traffic, especially long
distance traffic generating high toll, is being carried by means of
protocols that formally are not Fidonet standards. This creates an
ambiguity for such systems in indicating their additional
capabilities in Fidonet nodelist and in some instances, from being
listed in the nodelist at all.
This document attempts to document the current practice for
communication between two Fidonet systems via a reliable channel,
provide technical reference for Fidonet software developers and
eventually improve Fidonet connectivity.
1.2 Motivation for a new protocol
---------------------------------
Existing Fidonet Technical Standards and Fidonet Reference Library
documents [FTS-0001], [FTS-0006], [EMSI] specify both session
handshake procedures and transmission capabilities that imply:
* non-reliable communication channel between mailers
* low round-trip times in the communication channel between
mailers.
This was commonplace a few years ago, when Fidonet systems were not
using transport other than direct dial-up on a visible basis.
Things have changed today, when other communication media becomes
widely available on a day-to-day basis. This communication media
typically provides implementation of Physical, Data Link, Network
and Transport layers of the ISO/OSI Reference Model and facilitates
relieving Session layer of inappropriate functions, such as error
control, flow control, call management and data transparency
[Halsall95]. Examples of such communication media are TCP/IP socket
connection and HDLC family protocol connection.
New communication media can be generally characterized by the
reliable transmission service offered by it to the Session layer
protocol. Reliable transmission implies that:
* Data link and/or Transport layer protocols are responsible for
error control and delivery of frames in correct sequence
* Session layer and higher layer protocols are operating on top
of connection-oriented mode
* Quality of Service provisions (if any) result in unspecified
delays between transmitter and receiver
* connections are rarely aborted.
Combination of these factors imposed the following requirements for
the new Fidonet protocol:
* error control can be eliminated throughout the session layer
protocol for both handshake and default file transfer method
* session setup procedure should minimize number of
synchronization points for fast handshake
* protocol should be insensitive to delays and robust with
respect to timeouts
* application flow control should be moved to file level;
individual data frames do not need to be error checked nor
acknowledged
* protocol should be independent from both higher and lower layer
protocols
* protocol should be reasonably easy to implement and allow
future extensions.
2. Definitions
--------------
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
in this document are to be interpreted as specified in [FTA-0006].
However, for readability, these words may sometimes not appear in
all uppercase letters in this specification. Although it should not
impact minimal realization of binkp protocol, it must be noted that
Protocol Extensions may override, update or obsolete requirement
levels indicated by the above keywords in chapters from 3 to 6
inclusive.
Calling party in this document is referred to as the Originating
side and called party is referred to as the Answering side.
Originating side here is the party that initiates the connection
between two systems.
Mailer in this document is a software that implements the protocol.
Words "frame", "packet", and "block" when used in this document
refer to binkp's Frames, unless explicitly stated otherwise.
Other definitions that are not local to this document can be found
in the Glossary.
This document is organized as following:
Frames section defines binkp's frames. Binkp/1.0 commands and their
arguments section provides detailed description of all defined
protocol commands together with recommendations for their usage.
Actual binkp implementation may match it's own diagrams provided
that such implementation remains fully compatible with current
specification. Protocol states section gives rigorous state
diagrams for the minimum realization of binkp. All mailers MUST
support this minimum realization. Recommended Protocol Extensions
section documents most important extensions to the basic protocol
that are in use as of the time of this writing. The License,
Glossary and References sections can be found at the end of this
document.
3. Protocol Overview
--------------------
Binkp is a Fidonet session layer protocol intended for use over
data transparent bi-directional channels with reliable
transmission. There are no other requirements for the service
provided by the underlying protocol suite. Presentation and
application layer protocols are not discussed here. Whenever TCP/IP
socket is used, IANA registered port number for binkp 24554 SHOULD
be used (as registered with the Internet Assigned Numbers
Authority).
Functionality of the minimum protocol realization makes provision
for:
* password protected sessions
* 4D/5D addressing for Fidonet and technology compatible networks
* exchange of Type 2 [FTS-0001], Type 2.2 [FSC-0045], Type 2+
[FSC-0039] and [FSC-0048], Type 3 [FSC-0081] packets and
[FTS-0006] arcmail in both directions, including poll and mail
pickup, as well as transfer of any binary or ASCII files
* handling WaZOO [FTS-0006] file requests
* ensuring integrity of transmitted mail and files
* simultaneous bi-directional transmission
* maximizing performance over packet switched data networks
Binkp uses only one synchronization point during session startup,
that is password exchange. This feature facilitates fast session
startup for high latency links. Sliding window flow control is
incorporated on the file level. This ensures that a batch of small
files is transmitted with the same efficiency as a one large file.
4. Frame Format
---------------
Binkp is defined in terms of sending and receiving specifically
formatted data blocks. We call them frames.
Command frames carry protocol commands and may change protocol
state. Data frames are usually appended to files being received by
mailers or may be discarded, depending on the protocol state.
The particular way of mapping an octet stream or a datagram stream
of the transport layer into binkp frames may depend on the
underlying protocol suite. At this time, we define such mapping for
TCP/IP socket connection which can also be used for similar
transports as well.
The socket stream is being split into binkp frames in the following
manner:
7 6543210 76543210
+-+-------+--------+--- ................ ---+
|T| SIZE | DATA |
+-+-------+--------+--- ................ ---+
|<- 2 octets ->|<- up to 32767 octets ->|
(frame header) (frame data)
If T bit is 0, this is a data frame.
If T bit is 1, this is a command frame.
15 bits marked SIZE carry the size of the DATA part of the frame in
octets (with the bit marked 0 being the least significant). That
is, the actual length of a binkp frame is SIZE+2.
The size of the DATA part may vary between 1 and 32767 octets. A
correct realization should never set SIZE to 0. Upon receiving of a
packet header with the SIZE field set to 0, the total length of the
incoming packet must be treated as 2, this packet must be dropped,
and the event should be logged.
The first octet of a command frame data is the command ID. The ID
must be between 0 and 127 inclusive.
Other octets carry command arguments. Command arguments are an
arbitrary symbol string that may be null-terminated. Treating of a
null character in the middle of a command depends on realization
(with the options being "treat as whitespace" or "treat as
end-of-line"). The terminating null character (if any) is either
stripped or used by mailers internally as an end-of-line marker.
4.1 Notation
------------
As stated before, command ID is a small number between 0 and 127.
Every binkp command defined in this document has a symbolic name in
the form M_XXX. Symbolic names are defined in binkp commands
section. We will use symbolic names and not numeric command IDs to
refer to commands everywhere in this document.
The following notation is used to describe binkp's command frames:
M_XXX "Data string"
The actual numeric command ID for the command with the symbolic
name of M_XXX should be written into the first octet of the DATA
area of a binkp frame. "Data string" is a string to be copied into
DATA area starting at second octet. SIZE should be set to the total
length of "Data string" plus one for the octet to store the command
number. T bit should be set to 1.
4.2 Examples
------------
M_OK "":
7 6543210 76543210 76543210
+-+-------+--------+--------+
|1| 0 1| 4|
+-+-------+--------+--------+
| | +----- command ID (no arguments)
| +-------- frame length
+- command frame flag
M_NUL "TEST":
+-+-------+--------+--------+-------+--------+--------+--------+
|1| 0 5| 0| T E S T |
+-+-------+--------+--------+-------+--------+--------+--------+
5. Protocol Commands and Their Arguments
----------------------------------------
5.1 Classification
------------------
Protocol commands may be classified the following way:
* By argument type:
M_SKIP. Mailer MUST parse these commands and it is not
recommended to log arguments of these commands as they
are. Mailer-parseable commands can be further subdivided
by containment of a file name in the argument.
commands contain a file name in their arguments.
MAY ignore and/or log arguments of these commands.
* By protocol stage:
M_PWD (must not be sent by the Answering side), M_OK (must
not be sent by the Originating side). These commands MUST
never be sent during the file transfer stage.
These commands MUST NOT be sent session setup stage.
any time during the session.
5.2 File Name Issues
--------------------
In Mailer-parseable commands that contain a file name, the file
name MUST NOT include a whitespace (ASCII value 20 hex). The file
name SHOULD NOT include symbols other than alphanumeric
(A-Z,a-z,0-9) and safe characters as defined below in BNF. All
other symbols are to be considered unsafe and SHOULD be escaped in
the form of two hexadecimal digits preceded by a backslash (e.g. a
whitespace must be transmitted as "\20").
filename = *pchar
pchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe
safe = "@" | "&" | "=" | "+" | "%" | "$" | "-" | "_" |
"." | "!" | "(" | ")" | "#" | "|"
escape = "\" HEX HEX
National characters should not be escaped, but rather transmitted
using [UTF8] encoding (see section discussing non-ASCII characters
below).
The best current practice is that Mailer does not alter a file name
without sysop's intention. If the mailer does provide such a
mechanism, it MUST BE optional and it SHOULD BE off by default.
The protocol does not impose limitations on the file name length
other than those arising from the finite length of the binkp frame
itself.
5.3 Non-ASCII Characters in Command Argument Symbol String
----------------------------------------------------------
Generally, mailer SHOULD use only characters from the ASCII range
[32...126] in the symbol strings for command arguments. In case
when there is a necessity to use non-ASCII characters, mailer
SHOULD use the [UTF8] format of the multioctet Universal Character
Set [ISO10646]. Mailer SHOULD use non-ASCII characters only if the
other side have indicated it's support by transmitting M_NUL "OPT
UTF8" frame during the session setup stage. Otherwise, mailer
SHOULD assume that the remote does not support non-ASCII characters
and SHOULD NOT use them in command arguments.
5.4 Binkp Commands
------------------
Format: symbolic_command_name command_ID
M_NUL 0
Command arguments contain human-readable information, such
as nodelist info, sysop name, etc. This frame can also be
used by some Mailers to exchange protocol options. Mailer
MAY ignore and/or log arguments of M_NUL.
e.g. "ZYZ Dima Maloff"
The following format of M_NUL argument is recommended for
compatibility purposes:
* M_NUL "SYS system_name"
* M_NUL "ZYZ sysop's_name"
* M_NUL "LOC system_location"
* M_NUL "NDL system_capabilities"
* M_NUL "TIME remote_date_time"
remote_date_time format is described in [RFC822].
Example of valid remote_date_time is
Sun, 06 Nov 1994 08:49:37 GMT
* M_NUL "VER mailer_version protocol_version"
note: binkp/1.0 mailers should send "binkp/1.0" string
for protocol_version.
* M_NUL "TRF netmail_bytes arcmail_bytes"
traffic prognosis (in bytes) for the netmail
(netmail_bytes) and arcmail and files (arcmail_bytes),
both are decimal ASCII strings
* M_NUL "OPT protocol options"
here protocol options is a space separated list of
binkp options and extensions supported by the mailer.
* M_NUL "PHN string"
phone number, ip address or other network layer
addressing ID
* M_NUL "OPM string"
string is a message for the system operator that may
require manual attention
M_ADR 1
List of 4D/5D addresses (space separated).
e.g. "2:5047/13@fidonet 2:5047/0@fidonet"
M_PWD 2
Session password, case sensitive. After successful password
authentication of the remote, originating side proceeds to
the file transfer stage. This command MUST never be sent by
the Answering side.
e.g. "pAsSwOrD"
M_OK 4
Acknowledgement for a correct password. Upon receiving of
this command, originating side goes to file transfer stage.
This command MUST never be sent by the Originating side.
Arguments may be ignored.
e.g. ""
M_FILE 3
Space separated list of parameters for the next file to be
transmitted: filename; size in bytes; unixtime; file
transmission offset.
In protocol extensions, negative values for the offset may
have special meaning (see non-reliable mode for an example
of such usage), basic implementation may treat negative
values as an error.
Size, time and offset parameters are decimal. Until the
next M_FILE command is received, all data frames must carry
data from this file in consecutive manner. There is no end
of file identifier as the file size is known beforehand. If
there are "extra" data frames, Mailer may append this data
to the file. By default, transmission of each file should
be started from offset 0. M_GET command sent by the remote
MUST force the mailer to start transmission from the
specified offset.
e.g. "config.sys 125 2476327846 0"
or, answering to M_GET with offset 100:
"config.sys 125 2476327846 100"
M_EOB 5
End-of-Batch. M_EOB command must be transmitted after all
the files have been sent.
Arguments of the command may be ignored.
e.g. ""
M_GOT 6
File acknowledgement, that must be transmitted upon
receiving of the last data frame for current file.
Arguments for this command shall be the same as for the
M_FILE sent by remote, excluding the last argument, file
offset, which is not transmitted back to the system which
have sent M_FILE. M_GOT can also be transmitted while
receiving a file, in which case transmitting party may
interpret it as a destructive skip.
e.g. "config.sys 125 2476327846"
M_ERR 7
This command indicates a fatal error. A party sending M_ERR
should abort the session. Argument should contain an error
explanation and may be logged. Mailer sends M_ERR in
response for an incorrect password. Mailer NUST NOT abort a
session without sending a M_ERR or a M_BSY frame (though
state machine tables, for simplicity, may not include
"transmit M_ERR" instructions).
e.g. "Incorrect password"
M_BSY 8
M_BSY command is transmitted when the system encounters a
non-fatal error typically due to temporary lack of
resources to proceed with the session. The argument should
contain an explanation of the situation and may be logged
by remote. M_BSY may be sent at any time during the session
(including session setup stage), not only the stages
explicitly indicated in the finite state machine. The side,
which have sent M_BSY, is in legal position to abort the
session. Mailer MUST be able to accept M_BSY at any time.
Though state machine tables, for simplicity, may not
include handling of M_BSY command, Mailer MUST NOT be
confused by reception of M_BSY command.
e.g. "Too many servers are running already"
If a mailer wishes to suggest the remote a time interval
before the next session attempt, it may choose to transmit
it in the following format:
M_BSY "RETRY NNNN: explanation"
where NNNN is interval in seconds (decimal string) and
explanation is an arbitrary string containing explanation
of the matter (optional).
M_GET 9
M_GET command is a request to (re)send files. Arguments of
the command are the same as for the M_FILE command and
refer to a file which we'd like to receive from the remote.
Mailer may send M_GET when it doesn't like transmission
file offset (e.g. file was partially received during one of
the previous sessions).
e.g. "config.sys 125 2476327846 100"
Mailer reacts to this command as follows: according to the
first three arguments (filename/size/unixtime), it
determines whether the M_GET argument is the current file
being transmitted to the remote (or a file that have been
transmitted, but we are still waiting an M_GOT ack for it).
If this is the case, it should
* discard transmission in progress as soon as possible
* perform seek() to the specified offset
* proceed with transmission of the file requested
starting with an appropriate M_FILE.
For the example above, corresponding M_FILE will have the
following arguments: "config.sys 125 2476327846 100"
When the mailer is finished with transmitting data of the
requested file it may proceed with transmission of other
files it has for the remote.
M_SKIP 10
Non destructive skip. Parameter is a space separated list
of filename, size and unixtime. This command indicates that
the remote should postpone sending the file until next
session.
e.g. "config.sys 125 2476327846"
5.5 Example of Frame Exchange in a Simple Binkp Session
-------------------------------------------------------
+-----------------------------------------------------------------+
| Originating side | Answering side |
|---------------------------------+-------------------------------|
| M_NUL "SYS ..." | M_NUL "SYS ..." |
| M_NUL "ZYZ ..." | M_NUL "ZYZ ..." |
| M_NUL "LOC ..." | M_NUL "LOC ..." |
| M_NUL "VER ..." | M_NUL "VER ..." |
| M_ADR "2:2/2.2@fidonet" | M_ADR "3:3/3.3@fidonet" |
| M_PWD "password" | (waiting for a password from |
| | remote) |
|---------------------------------+-------------------------------|
| (waiting for password | M_OK "" (or M_ERR "Bad |
| acknowledgement) | password") |
|---------------------------------+-------------------------------|
| (got M_OK) | M_FILE "file2 200 42342434 0" |
|---------------------------------+-------------------------------|
| M_FILE "file1 100 423424244 0" | data |
|---------------------------------+-------------------------------|
| data | data |
|---------------------------------+-------------------------------|
| data | data |
|---------------------------------+-------------------------------|
| M_EOB | (got file1, acknowledging it) |
|---------------------------------+-------------------------------|
| (got file2, acknowledging it) | M_GOT "file1 100 423424244" |
|---------------------------------+-------------------------------|
| M_GOT "file2 200 42342434" | data |
|---------------------------------+-------------------------------|
| | M_EOB |
+-----------------------------------------------------------------+
6. Protocol States
------------------
The protocol has two major stages: session setup (different for
originating side and answering side) and file transfer (where state
machined for both sides are the same). Methods for initiating
connection as well as numerical values for particular timeouts are
dependent on the underlying layer's protocol suite and are not
considered here. Mailer MAY allow configuration of timeouts in
reasonably wide range to cover all supported transport protocols.
The Finite State Machine notation is used throughout this section
as defined by [FTS-0001].
6.1 Session Setup Stage
-----------------------
Originating side should initiate a binkp session according to Table
1. Answering side should be able to act according to Table 2. Any
optional extensions of the handshake procedure MUST NOT confuse the
other side, which may choose at it's discretion to follow this
minimal implementation. Upon successful handshake, both sides
follow Table 3 (file transfer stage). That's why terms Answering
side and Originating side were chosen for this specification
instead of Client and Server - both sides play the same roles, and
their state machines differ in session setup stage only.
Session setup stage has the following roles
* Authentication (REQUIRED). Answering side, upon reception of a
password (common secret word) from Originating side, decides
whether the password really matches the list of presented
addresses, and either acknowledges it by sending M_OK frame or
rejects by sending M_ERR frame. This mechanism is called Basic
Authentication Scheme and MUST be supported by all Mailers.
Basic Authentication Scheme has the following limitations:
* If Originating side presented multiple addresses, the
password for all of the addresses must be the same (may be
solved by Multiple passwords extension).
* Cleartext reusable passwords are passed over a network
(may be solved by CRAM extension).
* Verification is made on Answering side only, thus
Originating side has no way to verify Answering side (may
be solved by dual CRAM or public-key cryptography, not
discussed in this document).
* Indicating protocol options (OPTIONAL). Sides may exchange
specially formatted M_NUL messages to indicate supported
extensions. Sides MAY use another technique to indicate
extensions.
6.1.1 Originating Side
----------------------
Originating side sends M_ADR and M_PWD frames, waits for successful
authentication acknowledgement from the Answering side (M_OK frame)
and goes to file transfer stage. Originating side MUST NOT wait
before sending M_ADR frame, i.e. this frame should be send just
after setting up a connection on underlying layer. Originating side
MUST NOT wait before sending M_PWD except after reception of M_ADR
frame. The term wait in this paragraph means do not send anything
while expecting data from remote.
Table 1: Session setup, originating side
+-----------------------------------------------------------------+
| # | Name | Predicate(s) | Action(s) | Next |
|----+------------+------------------+---------------------+------|
| S0 | ConnInit | | Attempt to | S1 |
| | | | establish | |
| | | | connection | |
|----+------------+------------------+---------------------+------|
| S1 | WaitConn | Connection | Send M_NUL frames | S2 |
| | | established | with system info | |
| | | | (at least one M_NUL | |
| | | | "SYS ..." frame | |
| | | | should be sent | |
| | | | before M_ADR) | |
| | | | Send M_ADR frame | |
| | | | with system | |
| | | | addresses | |
| | | | Set Timer | |
| | | | See if we have | |
| | | | password for the | |
| | | | remote | |
| | |------------------+---------------------+------|
| | | Connection | Report no | exit |
| | | refused | connection | |
|----+------------+------------------+---------------------+------|
| S2 | SendPasswd | Yes, we have a | Send M_PWD | S3 |
| | | password | "password" frame | |
| | | | Reset Timer | |
| | |------------------+---------------------+------|
| | | No, there's no | Send M_PWD "-" | S3 |
| | | password | frame | |
|----+------------+------------------+---------------------+------|
| S3 | WaitAddr | M_ADR frame | See if answering | S4 |
| | | received | side presented the | |
| | | | address we've | |
| | | | called | |
| | |------------------+---------------------+------|
| | | M_BSY frame | Report remote is | exit |
| | | received | busy | |
| | |------------------+---------------------+------|
| | | M_ERR frame | Report error | exit |
| | | received | | |
| | |------------------+---------------------+------|
| | | M_NUL frame | Ignore (optionally, | S3 |
| | | received | log frame argument) | |
| | |------------------+---------------------+------|
| | | Other known | Report unexpected | exit |
| | | frame received | frame | |
| | |------------------+---------------------+------|
| | | Unknown frame | Ignore | S3 |
| | | received | | |
| | |------------------+---------------------+------|
| | | Nothing happens | Wait | S3 |
| | |------------------+---------------------+------|
| | | Timer Expired | Report timeout | exit |
|----+------------+------------------+---------------------+------|
| S4 | AuthRemote | Yes, the address | See if we've sent a | S5 |
| | | was presented | password for this | |
| | | | address | |
| | |------------------+---------------------+------|
| | | No, the address | Report we called | exit |
| | | was not | the wrong system | |
| | | presented | | |
|----+------------+------------------+---------------------+------|
| S5 | IfSecure | Yes, we've sent | Wait for M_OK frame | S6 |
| | | a password | | |
| | |------------------+---------------------+------|
| | | No, there was no | Report non-secure | T0 |
| | | password | session | |
|----+------------+------------------+---------------------+------|
| S6 | WaitOk | M_OK frame | report secure | T0 |
| | | received | session | |
| | |------------------+---------------------+------|
| | | M_BSY frame | Report remote is | exit |
| | | received | busy (Answering | |
| | | | size MAY report | |
| | | | busy after | |
| | | | reception of | |
| | | | caller's address) | |
| | |------------------+---------------------+------|
| | | M_ERR frame | Report error | exit |
| | | received | | |
| | |------------------+---------------------+------|
| | | M_NUL frame | Ignore (optionally, | S6 |
| | | received | log arguments) | |
| | |------------------+---------------------+------|
| | | Other known | Report unexpected | exit |
| | | frame received | frame | |
| | |------------------+---------------------+------|
| | | Unknown frame | Ignore | S6 |
| | | received | | |
| | |------------------+---------------------+------|
| | | Nothing happens | Wait | S6 |
| | |------------------+---------------------+------|
| | | Timer Expired | Report timeout | exit |
+-----------------------------------------------------------------+
6.1.2 Answering Side
--------------------
Originating side sends M_ADR and waits for M_ADR and M_PWD frames
from remote. Upon receptions of these frames, it decides whether
the password really matches the list of presented addresses, and
either acknowledges it by sending M_OK frame (and goes to file
transfer stage) or rejects by sending M_ERR frame (and
disconnects). The term wait in this paragraph means do not send
anything while expecting data from remote.
Table 2: Session setup, answering side
+-----------------------------------------------------------------+
| # | Name | Predicate(s) | Action(s) | Next |
|----+----------+---------------------+--------------------+------|
| R0 | WaitConn | Incoming connection | Send M_NUL frames | R1 |
| | | established | with system info | |
| | | | (at least one | |
| | | | M_NUL "SYS ..." | |
| | | | frame should be | |
| | | | sent before M_ADR) | |
| | | | Send M_ADR frame | |
| | | | with system | |
| | | | addresses | |
| | | | Set Timer | |
| | |---------------------+--------------------+------|
| | | Nothing happens | Wait | R0 |
|----+----------+---------------------+--------------------+------|
| R1 | WaitAddr | M_ADR frame | See if we have a | R2 |
| | | received | password for any | |
| | | | of the remote | |
| | | | addresses | |
| | |---------------------+--------------------+------|
| | | M_ERR frame | Report error | exit |
| | | received | | |
| | |---------------------+--------------------+------|
| | | M_NUL frame | Log | R1 |
| | | received | | |
| | |---------------------+--------------------+------|
| | | Other known frame | Report unexpected | exit |
| | | received | frame | |
| | |---------------------+--------------------+------|
| | | Unknown frame | Ignore | R1 |
| | | received | | |
| | |---------------------+--------------------+------|
| | | Nothing happens | Wait | R1 |
| | |---------------------+--------------------+------|
| | | Timer expired | Report timeout | exit |
|----+----------+---------------------+--------------------+------|
| R2 | IsPasswd | Yes, we have a | Set Timer | R3 |
| | | password | | |
| | |---------------------+--------------------+------|
| | | Yes, but we have | Send M_ERR frame | exit |
| | | several different | Report | |
| | | passwords for | inconsistent | |
| | | different addresses | password settings | |
| | | of the remote | | |
| | |---------------------+--------------------+------|
| | | No, there's no | Report non-secure | T0 |
| | | password | session | |
|----+----------+---------------------+--------------------+------|
| R3 | WaitPwd | M_PWD frame | See if the | R4 |
| | | received | password matches | |
| | |---------------------+--------------------+------|
| | | M_ERR frame | Report error | exit |
| | | received | | |
| | |---------------------+--------------------+------|
| | | M_NUL frame | Log | R4 |
| | | received | | |
| | |---------------------+--------------------+------|
| | | Other known frame | Report unexpected | exit |
| | | received | frame | |
| | |---------------------+--------------------+------|
| | | Unknown frame | Ignore | R4 |
| | | received | | |
| | |---------------------+--------------------+------|
| | | Nothing happens | Wait | R3 |
| | |---------------------+--------------------+------|
| | | Timer Expired | Report timeout | exit |
|----+----------+---------------------+--------------------+------|
| R4 | PwdAck | Yes, the password | Send M_OK frame | T0 |
| | | matches | Report secure | |
| | | | session | |
| | |---------------------+--------------------+------|
| | | No, password does | Report password | exit |
| | | not match | error | |
+-----------------------------------------------------------------+
6.2 File Transfer Stage
-----------------------
File transfer stage is based on two major routines. We call them
Receive Routine and Transmit Routine. These routines perform some
actions depending on their state variables. State variables are
RxState for Receive Routine and TxState for Transmit Routine.
RxState := { RxWaitF | RxAccF | RxReceD | RxWriteD | RxEOB | RxDone
}
TxState := { TxGNF | TxTryR | TxReadS | TxWLA | TxDone }
Table 3: File Transfer
+-----------------------------------------------------------------+
| # | Name | Predicate(s) | Action(s) | Next |
|----+--------------+---------------------+----------------+------|
| T0 | InitTransfer | none | Set Timer | T1 |
| | | | Set RxState to | |
| | | | RxWaitF | |
| | | | Set TxState to | |
| | | | TxGNF | |
|----+--------------+---------------------+----------------+------|
| T1 | Switch | RxState is RxDone | Report session | exit |
| | | and TxState is | complete | |
| | | TxDone | | |
| | |---------------------+----------------+------|
| | | Data Available in | call Receive | T2 |
| | | Input Buffer | routine | |
| | |---------------------+----------------+------|
| | | Free space exists | call Transmit | T3 |
| | | in output buffer | routine | |
| | |---------------------+----------------+------|
| | | Nothing happens | Wait | T1 |
| | |---------------------+----------------+------|
| | | Timer Expired | Report Timeout | exit |
|----+--------------+---------------------+----------------+------|
| T2 | Receive | Receive routine | Set Timer | T1 |
| | | returned OK | | |
| | |---------------------+----------------+------|
| | | Receive routine | Close all | exit |
| | | returned Failure | opened files | |
| | |---------------------+----------------+------|
| | | Receive routine | Call Receive | T2 |
| | | returned Continue | routine again | |
|----+--------------+---------------------+----------------+------|
| T3 | Transmit | Transmit routine | Set Timer | T1 |
| | | returned OK | | |
| | |---------------------+----------------+------|
| | | Transmit routine | Close all | exit |
| | | returned Failure | opened files | |
| | |---------------------+----------------+------|
| | | Transmit routine | Call Transmit | T3 |
| | | returned Continue | routine again | |
+-----------------------------------------------------------------+
Tables 4-6 are not actually state machines, but routines called
during file transfer stage
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 |RxWaitF |OK |
| | |-------------+----------+--------+--------|
| | |Got M_EOB |Report End|RxEOB |OK |
| | | |of Batch | | |
| | |-------------+----------+--------+--------|
| | |Got M_FILE |none |RxAccF |continue|
--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
|