[pskmail] Re: server install
- From: Rein Couperus PA0R <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 20 Dec 2006 15:35:42 +0100
On Tue, 2006-12-19 at 06:30 -0500, karel Fassotte wrote:
> yes Ralph and all, the suggestion to switch between, PSK64, PSK125 and
> faster modes like the 188-110a/b modems would be very attractive.
> I also suggest to integrate an IP interface to have a slow IP access
> to the internet.
Hi Karel & all¸
With the next version of pskmail you can manually switch between PSK63
and PSK125 during a connection. This feature is experimental, and I am
thinking about a way to do it automatically.
With regard to the IP interface the following:
* What exactly do you mean by 'IP interface' ? Interface between what?
* If you mean a socket with a transparent connection to the internet the
following issues need some thinking:
Speed
=====
In 1200 Bd packet radio the tcp/ip solution does not really work well.
That solution was to transport ip packets via a slow, overhead-prone
ax25 system.
That solution adds considerable overhead to the already ineffective
packet delivery system based on am addressing/routing system that used
ham radio calls (including the possibility to include up to 6
digipeaters in the heading). On 56k systems this is ok, although VERY
ineffective.
Pskmail does not use 1200 Bd but 125 Bd (PSK125). A factor of 10 less.
Timing
======
The timing requirements differ tremendously between TCP/IP and Pskmail.
With IP you are talking milliseconds, Pskmail uses seconds. A factor of
1000. This is the main reason for using agents (or gateways) in the
server to interface pskmail with the IP world. These agents look like an
IP socket to the internet, and like pskmail protocol to the air
interface. They decouple two vastly different worlds.
The trick is to strip as much overhead as possible, leaving maximum
bandwidth for the application. This also means that you want a connected
system, where address/routing information is handled once per
connection, not as part of every packet sent. This again implies a 1:1
relationship between client and server.
Be specific, not universal
==========================
Every application has its own characteristics, and in order to use the
scarce resources of pskmail we will have to optimize communication for a
specific application.
This means we have to settle for a finite list of applications for
pskmail. The socket approach would be much easier to implement, but it
will not work.
So one exercise will be to fix the application scope of pskmail.
Do you need telnet? Ftp? What are the priorities? What should an
application look like to the user? What should it accomplish?
One example is the email facility in pskmail. The user interface is
'evolution', which every operator is familiar with. Still, evolution
would not work with a universal socket in pskmail, it would simply time
out.
The constraint is the bandwidth. Pskmail is conceived as a QRP system
for mobile clients, so the less bandwidth the better.
something to think about over Xmas?
73,
Rein PA0R
Other related posts:
