home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.robotics
- Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!hpuerca.atl.hp.com!jab
- From: jab@hpuerca.atl.hp.com (Alan Barrow)
- Subject: Re: My robot project.
- Message-ID: <C0IFFM.277@hpuerca.atl.hp.com>
- Date: Fri, 8 Jan 1993 00:45:21 GMT
- Distribution: comp.robotics
- References: <1993Jan4.103239.10351@dunix.drake.edu> <1993Jan4.191739.26583@n1gva> <C0HsFB.BvG@jabba.ess.harris.com> <31474@nntp_server.ems.cdc.com>
- Organization: Hewlett-Packard NARC Atlanta
- Lines: 26
-
- Regarding buffering and packet radio, the more advanced protocols
- (TCP/IP) use an algorythm that optimizes the packet size.
-
- It tries to avoid small packets if possible, but will send them if it is
- obvious that more data is not coming. (Nagel "tinygram" algorythym?)
-
- This is discussed in the Comer TCP/IP book.
-
- This allows both small packet (typically interactive) use as well as
- large packets (file xfers, etc)
-
- There will always be some latency, however. Even at 56k packet (which I
- have connecting my unix machine at home to other ham's machines) it is
- an issue, as the key up time for nearly all radios is much longer than a
- typical packet. Thus any "non duplex" approach will suffer from this.
-
- I can point you in the right directions for public domain code, etc.
-
- Hope this helps!
-
-
- Alan Barrow km4ba | I've seen things you people wouldn't believe. Attack
- jab@atl.hp.com | ships on fire off the shoulder of Orion. I watched
- | C-beams glitter in the dark near the Tannhauser gate.
- ..!gatech!kd4nc! | All those moments will be lost in time -
- km4ba!alan | like tears in rain. Time to die. Roy Batty
-