Robert Thompson wrote: > You probably mean "Linux kernel-mode" AX.25, since JNOS runs fine on > Linux =)
Yes, I meant EXACTLY that. Kernel AX.25 can be fooled to endless repeats by TFPCX and an inadequate computer (say, a 286 running some terminal ....ughh !!) That has been a factual case for endless sysop/nodeop headaches. >> been a fairly good match to the radio channel characteristics for >> e-mail and web browsing over AX.25 packet radio. I used PCElm, and some other client with JNOS before I had a phone at home. I had my e-mail that way, using LZW compressed POP3 and SMTP. Not for exchanging photo albums, but perfect for mail contacts and even some ftpmail in small manageable chunks. The beauty of JNOS is the ability to tweak parameters, and topping maxwait, so the it is better able to hold the radio link. > Absolutely true! Two or three possibilities: Do what is sometimes > done for "internet satellite" terminals and "spoof" the TCP state > machine by locally generating ACKs, etc then committing to transfer > the frames yourself however you see fit. This works fine for some > things, terribly for other things. This is great for conditions where > the TCP client and server will break if their assumptions are tested > (Remember, 99.5% of modern internet apps *assume* ubiquitous high > bandwidth, low delay, low loss connectivity, and the timings that go > with it) It is a pity I cannot remember the names now, since that bad experience has piled up more than 10 years of oblivion. It was something capable of using a terminal with a packet driver and redirecting packets from 10 Mb/s ethernet to the serial port. It was a chaos generator, even on clear 2 meters channels with agressive fracks. > Alternatively, you can create "protocol gateways" that do non-TCP > over the air, with the other end acting like a "remote-controlled" > TCP client. I also used FBB forwarding for SMTP email over HF. It worked, but it needed a fairly clean channel to suceed, since the JNOS version did not implement the Z modem style code of the original FBB forwarding, and if the link failed, it could not continue from the offset it broke but rather had to restart the transfer from the beginning. > The HMTP smtp-variant can be thought of as one take on this, and it's > not too hard to implement a similar thing for straight POP or HTTP. > The result will work better (since neither the local-to radiobridge > TCP connection nor the remote-radiobridge-to-internet TCP connection > needs to have its timing fiddled with), but there are a LOT of > non-trivial edge conditions to deal with if you want the thing to > work with the internet "in the wild". Sadly, not reads internet RFCs > every night before bed... =) Yes, I have read about HMTP but have not actually tried it. I was rereading an article about it yesterday's evening.... Nevertheless, I already have telephone at home and a V-90 modem, so I have no need to do the past linking acrobatics. Seems there are more than 100 ways to boil a frog.... > (snip) >> packet sizes. Even on 2 meters 1200 baud links, it creates havoc. > > Heh, you want a feel for exactly how bad the problem is? Try using a > GSM/GPRS (others might do this too, but GSM/GPRS guarantees this > ability) cellphone to make a 9600 baud "dial up" connection to an ISP > modem (or whatever you have handy). I have been tempted to try it, but it is E X P E N S I V E....I rather use the V.90 modem. > Note, this is *not* whatever "high speed" connection your provider > offers. This is 9600 baud, fairly long latency with occasional > latency spikes due to scrambled-and-resent data frames. A lot of > modern software does *not* function over this vastly better > connection. I've actually seen a client (a chat client, not that it > matters) successfully connect, then queue up so much XML status > information that the connection *never* succeeded at passing any > actual information. Linux AX.25 taught me a vastly better implementation than what I had seen in MSDOS and Windows. I used standard browsers and it was usable for ftp and textual HTML. Images seem to be always heavy. You could feel the slowness, but with a lot of patience, it did work, qnd I would say it did its job well. All that at 1200 baud. And I even could finish quite a few ftp transfers on HF at 300 baud. Small files, from 10 to 50 K were perfectly transferable. > (snip) > >> But it is clear to me that you CANNOT expect that a bandwidth >> bottleneck like a radio link, particularly a HF radio, to perform >> as a 10 or 100 Mb/s (say) wired LAN. Otherwise, mating a LAN with a >> radio link without the appropiate traffic downsizing is doomed to >> failure. > > A: You need applications that are aware of their link resource, or > else are OK with batching traffic and offloading actual delivery to > some other tool. Certainly. RedHat 5.2 and 6.2, (and possibly others as well) performed as expected in a SLOW link. A feat Windows is uncapable of. > B: even 802.11b/g has to significantly adjust the timings "under the > hood" in any enterprise campus location. Much of the inefficiency a > large wifi location sees is due to the fact that the actual layer 3 > protocol (TCP in this case) timings aren't dynamically adjustable, so > layer 2 has to try to provide what layer 3 has been tuned to expect. > That's doomed to fail, then. > C: Amateur radio networks aren't best modeled by the modern TCP view > of the internet anyway. They're a much better approximation to the > old asynchronous-bundle-delivery UUCP days (although we have learned > a few things since those days; no need to be "mistake-compatible" > with UUCP =) Most useful things can be turned into bundles that can > be transferred to the peer whenever the peer can be reached. Unlike > UUCP, however, there must be at least some ability for ad-hoc > pathing-peering discovery, since HF is much different than a > scheduled telco-hardline dialup link. > > (snip) > > >> There is no problem with RFC821 or RFC822, it is just a matter of >> what kind of channel access parameters are used. If they are >> matched to the channel properties, it may be OK, but otherwise, it >> will be entirely flawed. > > Yes, in general, rather than trying to cram a legal ham HF/VHF link > under the existing internet layer 2 protocols, which at best results > in *terrible* efficiency, average throughput (whatever the peak may > be), etc, it's usually better to implement application protocols that > are a better fit to the channel constraints. Yes, you *can* adapt IP > protocols enough so that they'll work; once you've done that, almost > all applications written with the internet in mind will break > anyway. Certainly...on Windows...I was amazed to be able to use standard Linux clients. And I even ran an Apache server accesible from the radio link. But it required light pages to be useful, from conscious people that value bandwidth appropiately and do not want to flood your screen with Flash content. It is a rare virtue. Web programers should be taught to try their pages on long congested links, and not on their gigabyte LANs. Also, about the value of RAM space and the nastyness of memory leaks. But many do not even know that Apollo computers flew with 64 KB of that rare commodity that was ferrite core memory back then, and think that assembler is an arcane language. It is interesting that among the Unix community, that light page it is a quite common style for technical pages, even with "ASCII graphics". The value of an idea is certainly not based on the use of beautiful word processor fonts. I am aware that such a spartan style "does not fit all", but nevertheless, feel it is quite useful. I am aware that the dark ages are a thing of the past, but Santa did not always bring me all the toys I wanted...I have not forgotten that. > Just for fun, go look up the timings embedded in the HTTP/1.1 spec, > and imagine trying to meet the timeouts over a HF channel. Now note > that a large subset of the internet is unreachable from a HTTP/1.0 > client... specifically *every* host that uses "name-based virtual > hosting", which is almost everything. Just one example. Expect to > trip over hundreds more. No, I have never gone deep into it. But I feel my curiosity aroused now. Thanks for the neurone massaging reply. 73, Jose, CO2JA __________________________________________ Participe en Universidad 2008. 11 al 15 de febrero del 2008. Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.universidad2008.cu
