Re: tlf-0.8.1 full network version is ready for testing
On Friday 04 October 2002 16:54, Jaime Robles wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El Jue 03 Oct 2002 21:59, Rein escribió:
> > Version 0.8.1 is the long-awaited (by some) networked version for
> > multi/single and multi/multi operation.The network can contain up to 8
> > (or 64) tlf nodes, which share log, dx_cluster data, bandmaps, frequency
> > data, local talk, serial numbers etc. via a simple/fast udp protocol.
>
> I have some technical questions and a few "wishes" for the next version...
>
> The main problem i have detected in CT when using a multi/multi
> configuration is the next issue.
> Just imagine you have several stations with several PC connected running
> CT.. some times the RF causes some errors in the transmision of contest
> data.... so as the contest goes, scoring starts to be different on each
> PC-station.... and at the end of the contest you have several computers
> with different number of qsos and different score...
>
> Does tlf take care of this problem?
At this moment tlf does not take care of this, I wanted to test the
ruggedness of the system first without going into too much overhead.
I have of course been thinking a lot about this... I have so far been quite
lucky with the networks we used (but I've only worked with Multi/single
stations).
The system used by tlf is to try and make sure the log is duplicated at each
node. To achieve this, every node sends the qso info to every other node.
If there are no faults on the network, all logs are the same after the
contest . If there are faults, some logs miss a number of qso's.
What you should do after the test is take the logs off the nodes and do a:
"sort +3 node1log node2log | unique > finallog" or similar...
this will sort the log with increasing qso numbers and take out the dupes. If
you then restart tlf with this final log it will score it properly. Then
write the cabrillo file...
Of course this does not solve the problem of having a wrong score indication,
and also the dupe check will not be complete if qso's are missing on your
node. But system-wide, no qso will be lost!!
Tlf also counts the number of send errors, which indicate that a node is not
present on the network. This can also indicate network problems. (:info
display).
> Maybe an error protocol could be designed to fix that.
I could build in an ACK routine for the qso data messages, so a node could
resend the data to a node which does not acknowledge. But how often should we
try? and for how long? A qso rate of 300 at 3 nodes makes 900 per hour, which
is 1 qso every 4 seconds... But are we not reinventing tcp here?
When the network is bad, also tcp will not deliver the info on time...
> Maybe based on the score and/or the serial number...
I already do this for the wpx contest, which uses serial number exchange. The
serial number is broadcast at the moment it is sent to the keyer, so the
other nodes know it is not available any more.
This is a nice example of how complicated things become when you allow more
than 1 node... If I send serial nr. 756 to W1AW, and it takes them 30 seconds
to copy the exchange and finish the qso, theoretically the other nodes could
increade the qso counter by 7. If at that moment the network is not
functioning properly I have no chance to know what my next serial nr. is!!
Tcp will not cure this, it will just deliver the information too late and
with more ovrhead.
> If you add the serial number of the last qso worked on each packet you send
> to the net, you can check it on all the stations and then ask for qsos you
> have missed...
The qso number is already part of the qso data message. But whom do you ask?
You don't know from which node the missing qso was...
> I am with Rein in the use of udp... because the same rf problem you cannot
> use tcp as the connection would be broken quite often... but i think it is
> very important some kind of error-control-protocol...
>
> Do you know what i mean?
I know what you mean, but I think it is better to make sure the LAN works
o.k., and then put an error-control-protocol on top.
I will do some thinking...
>
> On the other hand i have been reading the tlfdoc and i like the way you
> have solved the problem of the station ID but maybe you could save some
> "bytes" without that... maybe the IP number would be enought for that...
I use the station ID for checks, and this was the easiest and fastest way
(integer, without decoding). At 10 MHz it takes only 1 microsecond to send a
character :-)
> You can just name the stations with their IP and then in the program
> controlling who is each IP.... some packets at the begining of the program
> to identify each station and then no more packets with the "station's
> name", just the IP.
>
> The talk function is important ;-) and maybe a "private talk"... to inform
> just one operator without disturbing the rest... but that would be just for
> the TODO list ;-)
This is on the TODO list..
>
> The main issue on the net chapter for me is the error control. :-)
> I am going to test tlf network just know. :-)'''
> Thanks!
Hope you have fun with it Jaime... And if you have a SIMPLE idea how to
improve, just Yell...
73, Rein PA0RCT
P.S.: when you initialize the variable debug=1 in background_process.c you get
a log of the tlf messages on the LAN...
>
> - --
> Un saludo,
> Jaime Robles, EA4TV
> jaime@robles.nu
>
> Visita http://www.redlibre.net - La Red Libre de todos!
> http://smsdx.net - El DXCluster en tu movil!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE9nauXER46oL+8yYURAm5UAJwORC+MNCafD9RDc3i8WNgv4a2VCQCbBpxX
> o7iE9MsmwMSim2TPE/msVjs=
> =0qGx
> -----END PGP SIGNATURE-----
Reply to: