Date: Mon, 04 May 1998 13:15:13 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: jbryant@unix.tfs.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: Infrared ? (a simple experiment for laptop owners...) Message-ID: <199805041715.NAA05031@whizzo.TransSys.COM> In-Reply-To: Your message of "Mon, 04 May 1998 11:58:27 CDT." <199805041658.LAA06135@unix.tfs.net> References: <199805041658.LAA06135@unix.tfs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> In reply: > > > Did anyone see my last posting on this topic? > > > > > > These ports are ideal for AX.25! HDLC/LAPB type protocols are well > > > documented. IP can be tunneled easily, as a matter of fact there are > > > half-duplex TCP/IP networks all over the world using these protocols. > > > > AX.25 does a very simple CSMA channel access algorithm, but there > > is no collision detection done (or possible). AX.25 exhibits worse > > that is the purpose of the ack/nak sequences [rr] frames... That simply recovers the lost frames, rather than arbitrating channel access. > a level of pre-transmit collision prevention is done by monitoring the > squelch line or the tone detector for channel activity. > > > yet you'll interfere with his transmission.) The original implementations > > didn't do an exponential backoff (and I suspect many still don't) which > > produces a very entertaining congestive collapse of loaded channels. > > exponential backoff has been pretty much de-facto standard since the > mid-eighties or so. And how many turn that off to get "better" service? > > There have been some attempts to improve the scheme - using full duplex > > VERY expensive [$3000+ per node] given the nature of the communications... The end stations needn't be full duplex; you could run the stations through a repeater to eliminate the hidden terminal problem. > > > If anyone is interested, if I remember correctly, I have a copy of the > > > AX.25 protocol available at my web page [see .sig]... I can also > > > supply the LAPB docs. > > > > Implement an AX.25 if you want to talk to the existing RF systems, but > > you can do much better than this starting with a clean slate. AX.25 was > > an experiment that escaped from the lab, and now the Amateur Radio > > I can think of a few better [?] ways of doing things myself. The > problem at hand right now is a similar one, how to take a half-duplex > serial link, and do something useful with it. there seems to be no > point at this point to ask why they didn't specify a WDM/TDM solution to > provide full-duplex communications in the IrDA standard. We are stuck > with half-duplex. It's not the HDLC that's the problem. You need some packet framing protocol. The problem is that HDLC doesn't presume that it needs a channel access protocol; since it presume a full duplex channel, you simply transmit when you want to. To make things work in a half-duplex environment, you either put up with the low effective channel capacity due to collisions trying to use the channel, or you take active steps to mediate access to the channel. For example, you could have a master/slave approach where the master polls the slave. You could have variations like slotted ALOHA or TDMA. There has been some work in this area; see Karn's BTMA (Busy Tone Multiple Access) proposal for one approach that wasn't adopted. > HDLC should be a common factor here, in amateur radio tcp/ip, only the > HDLC layer is used, with IP directly on top of that. That's OK for channel framing, I suppose. > If async is not desired, then mebbe a TDM method would be more > appropiate, nice for a finite number of nodes... You have geographical proximity and common adminstration at your disposal. This means there shouldn't be problems designating something a "master" and polling, for instance. Or you put up with the suboptimal throughput with no explicit channel access. My main point, I guess, is that you shouldn't hold up AX.25 as a well engineered solution. Learn lessions from it, but don't be blind to its problems. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805041715.NAA05031>