[pskmail] Re: Python Client Testing and Stream IDs
- From: Rein Couperus <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 10 Nov 2008 17:35:47 +0100
That is how it is meant to be. The server sets the stream number.
This is also clearly described in the ARQ2.pdf document.
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.
If necessary the client can refuse the stream ID by reconnecting, the server
will then issue the next stream ID.
If at a later stage when we introduce multi-connect, the client will have to
make connect for every single session. In the case of DAMA access control
the client will have to request for a slot, and the server will issue one.
In that case a slot (i.e. connect) will also be necessary for asynchronous
traffic
like APRS messaging. E.g. beacon slots could be provided with a predefined
period,
and the server will poll the client when the time comes.
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.
73,
Rein PA0R
> -----Ursprüngliche Nachricht-----
> Von: "William" <va3udp@xxxxxx>
> Gesendet: 10.11.08 16:51:47
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Re: Python Client Testing and Stream IDs
> Le 08-11-10 à 16:33, Rein Couperus a écrit :
>
> > William, you did not look closely enough :)
>
> Could be :) But I think there may be something funny going on.
>
> The comment I refer to is this one in arq.pm:
>
> ############################################################
> sub ttyconnectblock { # Connect (caller:port, my:port)
> # c block = Caller:port My:port <streamnr. (0)> <max. blocklen>
> # e.g.: '00cEA3FG:87 PI4TUE:87 4'
> ############################################################
>
> The "c block" line comes from page 3-4 of ARQ2.pdf but the
> example immediately below it drops the stream number.
>
> > TX (2008-11-10 15:20Z): <US><SOH>00cPA0R:1024 PI4TUE:24 5F258<EOT>
> > RX (2008-11-10 15:20Z): t t O<US><SOH>0#kPI4TUE:24 PA0R:1024
> > 53336<EOT>
>
>
> A problem I see when done like this is that the client cannot
> pick it's own stream number - The client might want to use %,
> and the server should send packets with that as the second byte.
> When the client sends packets to the server it would use #.
>
> If a client wanted to make multiple connections to the server,
> or to multiple different servers, there would be no way to
> distinguish the streams I think. Especially in later packets
> that don't necessarily carry the callsigns.
>
> Or do I misunderstand?
>
> 73 de William EA5/VA3UDP
> va3udp /@/ rac.ca
>
>
>
>
>
>
--
http://pa0r.blogspirit.com
Other related posts:
