Hi Rein, Am 2014-07-08 10:59, schrieb Rein Couperus:
I've taken a quick look at QTC-net, and I have come to the conclusion that it will be quite easy to add QTC-net capability to pskmail (and vice-versa). Integration will be quite easy, as both QTC-net and PSKmail server are written in perl.
I am really glad to hear this from you. My favorized version is to set up a local QTC-Net node oneach PSK-Mail Server system, that syncs with the other nodes. That provides
best access even in times of disaster.
PSKmail could offer the following services to QTC-net: 1* Send QTC-net telegram from a pskmail client to QTC-net server via a pskmal server (unproto) - using telnet, curl or whatever....
With a local node it would be a filesystem drop, that is well scripted within in the qtc librarys.The difficult thing is to decide what finally should go over the radio link:
- One scenario is that the JavaPSK Mail Client has a public private key pair and produces and receives signed qtc messages. The client would also have full control over every qtc-net setting, like aliases and followings then. As soon as a message is signed, it is unique, and from this point on it can be distributed and
multicasted without the need of any extra communication.For this scenario we have everything we need, a client software that can hold a private key and a message processing logic as well as a set of independed servers to exchange
data with.Unfortunately, right now, this means a protocol overhead of 300 Bytes per Message due to the fact that the ssl signature is 256 bytes long. This is a lot for max 300 Byte telegrams. The Signature size could be reduced to maybe 32 bytes by using another crypto library that uses smaller checksums, but that means more access specific code to the clients. Anyway a message is most of the times between 350 and 400 Bytes, 6.5 s per Message with PSK 500, fair enough, how many messages do we
expect?This scenario also means that a Java library is needed that is capeable of parsing and creating QTC Net Messages which is a bit of work, but it also
enables JavaPSK Mail or any other java app that utilizes that lib, theoretically, to be a QTC-Net node by itself, if it would download allnetwork data available instead of just the information it currently needs.
- We could transmit only the human readable data, from, to and text, leaving it to the Server node to keep a Key and be the publisher within the QTC net.
I am doing that between APRS and QTC-Net.But this would mean that you either distribute username/passwords for alias changes, or that you don't do alias changes at all and the user has to wait until he has a Internet connection again. You also wouldn't have the posibility to multicast messages, with the aprs gate I have to make some colission detection between the gates as soon as a Message gets forwarded. happily APRS is designed to be realtime, but it means that there are some states to be sent between the
IS Gates.However I made an http-xml interface that is attached to the webfrontend. And I did this so that App developers especially those who don't have perl apps, do not have
the need to implement the all of the QTC-Message Specs in their clients.
2* Deliver QTC-net telegrams to pskmail client via pskmail servers usingany mode supported by fldigi
I would just rely on the existing structure here.
3* Deliver CW telegrams to users automatically (multicast or targeted tocall...).
I thought especially about a scenario with an operations mode where someone calls CQ QTC de CALL and a station comes back with CALL de STATION2 QTC number .... Not as the way to access, more as a way to access when there is no computer or data platform available. So my original Idea was to make this manually, especially for CW, with a nice diplome for the operator that is the publisher (STATION2 fromthe example. That STATION2 needs publisher access using software to connect
to qtc-net either via Internet or via HF, or via whatever.
Let me know what exactly you want pskmail to do for you...
I hope that it was not to badly described and confusing, or information overload. I would like to focus on the first scenario that I described above, with the jpskmail client processing the QTC-Net messages, because it is the most flexible version, and it is also a bit new on amateur radio links.If the signature size really is a problem we may still decide to leave signatures partly away wich disables message forwarding, or what I would prefer, to change the signature algorythm to something a bit less secure, but more hf friendly, or even decide to use a quick access instead the mentioned qtc-net java library
that needs to be written. 73 de Hans (OE1SRC) -- This final error message indicates a successful installation of a UNIX GIS cluster node. This is not an error, as the misleading message may suggest. (found at Sterling Commerce Knowledgebase)