Jose A. Amador wrote: > Based on what I know, for SMTP, JNOS may be an option at less than 300 > baud, i.e., 100-110 baud or PAX, using MultiPSK as "soundcard modem". > > I have not tested any of it yet. I have had no time and possibilities to > test it so far. > > JNOS can use FBB compression or LZW compressed SMTP on any of its radio > ports using KISS protocol to connect to a TNC. > > I ran both FBB and JNOS simultaneously for several years sharing the > same TNC under MSDOS and Linux, and HF mail using compressed FBB > protocol or LZW compressed SMTP worked, even when painfully slow, at 300 > baud on a shared forwarding frequency. Even FTP worked (I do not > remember if it could be compressed as well) on HF. > > It is not theoretical. JNOS networking works on HF with the known 300 > baud weaknesses. How well does it work really matters when nothing else > is available? Certainly, that may be an option in an unconnected scenario. > Yes, I understand "it works". FBB works OK on HF because once you are logged in, it's not that interactive. But you still have 2-3 turnarounds before you send the initial message, etc.
Buried inside the P3 WL2K pactor transfers is a basic F6FBB chat & login. Typically 5-10 seconds to link, get logged in, and sync prior to really transferring the messages. Again, it works, lot's of messaging sent this way. But a bit wasteful. Why are you logging in when the system already knows who is sending it via your callsign? And you just sent the password in the clear on hf, so why bother? Login's are wasteful on HF. Lot's of analysis & discussion in this area as well. Real answer is a public/private key system. Anything else is wasted time & bandwidth. Adds no security, and reduces reliability. SMTP over HF is much less efficient & reliable because it has many, many turnarounds. It's designed for a lan with infinite signal to noise ratio. :-) short packets, many turnarounds. With more overhead in the TCP/IP header than in the data sent. So in the commercial & military systems, you see TCP/IP spoofing. Eat, then recreate the IP headers on the opposite end. Same for SMTP. (just like the trailblazer modems did with UUCP in the old unix days) So how do you deal with this using the tools you have? With BBSLink we use an FBB command structure, but compress the initiation of sending the message into a single file transfer. IE: the command, user ID, etc is prepended to the message and processed by bbslink. So no login chat over the air, retries, etc. With HF, you only get so many seconds of decent S/N at times. You don't want to waste half of your window getting logged in using a system oriented for interactive users. If the message is short enough, it's a single send, then ack back from the receiving system. Longer messages do have an ack before the next frame is sent, etc. DBM is not perfect, but works, and is a true WW standard. (for as much as that means... F6FBB is also a defacto standard but there are very many implementation differences in login specifics, etc when talking to them programatically.) We'd like to see other protocols like FAE, etc leveragable as well. So could you make JNOS/MSYS work over HF with a kiss modem? Most likely. Is that the best way? I think we can do better if we apply ourselves & work together. JNOS is certainly a useful tool in the mix. I know of unix systems still using JNOS as transport. :-) If we scratched deep enough we'd find some in use on corporate routers. Have fun! Alan km4ba
