[pskmail] Re: Questions
- From: rein@xxxxxxxxxxxx
- To: pskmail@xxxxxxxxxxxxx
- Date: Tue, 9 Oct 2007 17:34:23 +0200 (CEST)
See comments below:
On Wed, 03 Oct 2007 15:04:32 -0400
Goody K3NG <goody.k3ng@xxxxxxxxx> wrote:
> 1. When a client sends out a beacon, the server sends out an
> unidentified QSL. Theoretically multiple servers may simultaneously
> QSL, so the client and everyone else listening can't really tell who is
> responding. Can it be made so the server waits a random number of
> seconds (0 to 10) and responds with something like:
>
> <US>QSL K1ABC DE K3NG<EOTSign>
>
> This way everyone can see when multiple servers can see a client and
> servers can even see other servers (beyond just hourly beacons). This
> feature could be expanded later and come in handy for the
> server-to-server protocol or building routing tables.
I like this idea. We have to make sure it does not interfere with traffic.
Better format is: <SOHsign>QSL K1ABC de K3NG<EOTsign>. The <US> is only
used as a preamble.
>
> 2. I've been watching server logs and I think I have a decent
> understanding of how things work. I don't quite understand the
> missing= parameter. It shows some data when there are unacknowledged
> packets on the other end (i.e. good != end), but it's not always
> numeric. Is this a binary encoded parameter that enumerates the frame
> numbers that are missing? How do you decode it? Could it just be
> outputted in the log already decoded like:
>
The 'missing' parameter is really a debugging indicator, it shows which
blocks have not been received correctly. The format is the 'block number',
coded as a character, the ASCII value is 'number + 32'.
We could simplify that by by just stating how many blocks are missing.
> Also, what is the meaning of the 'last' parameter? I always seems to be
> a few behind 'good' and 'end'.
The last parametr means the last data block the other side has received
correctly from you.
> 3. It doesn't appear that server transmissions are logged, other than
> the Disconnect message. Could all transmit data be logged, along with
> the decoding of what the message is like is done with received messages?
>
Yes, that is easy to do.
> 4. Can multiple clients be connected to a server at once?
>
Not at the moment. We need a better DCD mechanism for that, it would create
havoc on the qrg at the moment. It is foreseen in the protocol, so we can
add that in the future.
> 5. Could the logs more clearly identify who connected and disconnected,
> like:
>
> 16:05 UTC Oct-3-2007: > Disconnect: K1ABC
>
Yes.
> 6. I noticed during idle time of a client/server connection that
> there's a lot of redundant status messages tossed back and forth, and
> usually there is a disconnect after some time. Are the status messages
> going back and forth really necessary? What is the criteria for a
> disconnect to occur?
>
I could reduce that at a later stage, depending on whether there is text
waiting to be sent. This proocol needs very tight coupling for it to work.
The criteria for disconnect is the number of poll frames sent. Server version
0.4 does not do this correctly.
> 7. I'm getting a lot of Use of uninitialized value errors on line
> 1232 in arq.pm. Looking (very briefly) at the perl code, I see
> however everywhere else there's a variable called
> (note the case difference with the L). If I recall
> correctly, Perl is case sensitive and these would appear to be different
> variables and perhaps a bug?
>
It is a bug, solved in version 0.5.
73,
Rein F/PA0R/P
Other related posts:
