>
>> That's the way it works. There's nothing better - If you
>> think through the
>> possibilities, there really isn't any better practical way to
>> handle it.
>
> Yes, there is. It called client-server. One PC acts as a server and issues
> serial number from its pool UPON request (grey + on the mult station in my
> implementation) and takes it back when grey- is pressed. In this case the
> returned nr is given out only when the consecutive nr is not issued yet.
>
> Any PC can be the erver in the network and needs the starting nr of its
> pool
> to be confirmed when it gets the server status.
>
> 73!
>
> Zoli ha1ag
>
I guess it depends on what you think is "better".
It has been my opinion, and remains my opinion, that designating
a "server" to allocate serial numbers will cause more problems
than it will solve because you have to deal with the possibility
that a client might not be able to reach the server when it
needs to.
You have to decide whether to forbid such a client from making
any QSOs, or whether to let him run with out-of-order or duplicated
serial numbers. If you decide to allow the second, then why bother
with the client/server allocation dance in the first place?
If you decide on the first, then you have to guarantee your
network is rock solid across all clients to the server 24x7.
When contest sponsors start penalizing out of order or
duplicated serial numbers, then contesters might be willing to
pay for the hardware/software necessary. Until then....
Wayne, W5XD
|