[pskmail] Re: PSKMail and QTC-Net
- From: Hans Freitag <zem@xxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Tue, 08 Jul 2014 16:00:59 +0200
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 on
each 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 all
network 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
using
any mode supported by fldigi
I would just rely on the existing structure here.
3* Deliver CW telegrams to users automatically (multicast or targeted
to
call...).
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 from
the 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)
Other related posts:
