[pskmail] Re: Python Client Testing and Stream IDs
- From: Rein Couperus <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 10 Nov 2008 20:41:56 +0100
From ARQ2.pdf:
Block type 'c', connection request:
quote
The connection request will be sent to the 'undefined' stream of the receiving
station,
(i.e. '0'). The Connect Request is by definition block #0.
unquote
I think what you mean is not the stream ID, which is a replacement for the call
signs in ax25,
but the port number which in our case is fixed at 1024 for the client, but can
be changed to
reflect tcp ports as soon as we start programming sockets...
So generally spoken, when a client has more than one connection, it will have
more than
one outgoing port open... These ports would run from 1024 to 32768... Actually,
there is a lot more which has to be defined when we go over to multi-connect.
73,
Rein PA0R
> -----Ursprüngliche Nachricht-----
> Von: "William" <va3udp@xxxxxx>
> Gesendet: 10.11.08 18:25:49
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Re: Python Client Testing and Stream IDs
> 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
>
>
>
>
>
>
--
http://pa0r.blogspirit.com
Other related posts:
