[pskmail] Re: Python Client Testing and Stream IDs
- From: William <va3udp@xxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 10 Nov 2008 18:25:06 +0100
Le 08-11-10 à 17:35, Rein Couperus a écrit :
That is how it is meant to be. The server sets the stream number.
This is also clearly described in the ARQ2.pdf document.
Please indulge me a little. I've re-read the spec several times, and I
don't see that. Quoting from page 4,
If OA2VR/VE3 wants to open a connection to a SMTP server at
5Y3GTB's station, assign it to stream 1 with 256 byte blocks
... the string would be "OA2VR/VE3:1023 5YGTB:25 1 8 ..."
And further down in the acknowledgement section,
The message is the receiving station's version of the connection
request ... for example if [5Y3GTB will] accept the request as
stream 2, the reply of "5Y3GDB:25 OA2VR/VE3:1023 2 6 ..." will
be sent to OA2VR/VE3's stream 1.
It also makes sense. When more than one client is connected to a
server,
it is the server wants to control the stream id, not the client.
As I understand the spec, a connection is made up of two streams, one
in each direction.
If necessary the client can refuse the stream ID by reconnecting, the
server will then issue the next stream ID.
I think the other way around -- if a client choses a stream id (for
server -> client data) that is already in use by another client, it
would be the *server* that would refuse the connection. For data going
from the client -> server, the client can just use whichever stream
id it is told to.
In all cases the server keeps control of the channel. DAMA is
necessary for
multi-connect because of the enormous HF footprints of the servers,
where
CSMA/DCD access control does not work.
Sure, but I think this is an orthogonal issue. The server can still
instruct the client how (which stream id) and when to transmit. The
issue is the stream ID the server uses to transmit.
Consider a client that makes connections to two servers simultaneously.
What if they both chose the same stream ID for sending data to the
client? How would the client tell which data came from which server?
I think it is always the recipient of the data that specifies where
they are going to receive the data.
Consider an implementation of classical FTP (not that it would make
sense to implement this, but for other reasons). Where the server
makes a connection back to the client to transfer bulk data. The
client's algorithm for accepting the connection would be just like
the server's, no difference.
The ARQ2.pdf seems to talk only peripherally about clients and servers
as such, the primary distinction being (as with TCP) who is initiating
and who is accepting a particular connection rather than topological
considerations...
Cheers,
73 de William EA5/VA3UDP
va3udp /@/ rac.ca
Other related posts:
