jackson@Neon.Stanford.EDU (Robert D. Jackson) (11/02/90)
I'm searching for vendors that sell TCP/IP source code. I have found two: Wollongong and Interactive Systems. I've been able to experiment a little with binaries from Wollongong (AT&T 6386, Unix System V, Rel 3.2.1) and have gotten a few comments from others that have used it. I have not been able to locate anyone that has had experience with the Interactive software. If you have had experience with the TCP/IP software and/or support from either of these vendors, good or bad, please drop me a line. If you know of another place I should look for TCP/IP source code, please let me know. Thanks in advance, -- Bob Jackson jackson@neon.stanford.edu
romkey@ASYLUM.SF.CA.US (John Romkey) (11/03/90)
A third vendor of TCP/IP source code is Epilogue Technology. We announced a portable TCP product at Interop. Email me for more information. Many people use the Berkeley code as a start. It's an excellent protocol engine; its main drawback is that it really really wants to live inside a UNIX kernel. It often takes many man-months to port properly. You can find it on uunet.uu.net for anonymous FTP. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141
hwajin@yuba.UUCP (Hwa Jin Bae) (11/06/90)
>Many people use the Berkeley code as a start. It's an excellent >protocol engine; its main drawback is that it really really wants to >live inside a UNIX kernel. It often takes many man-months to port >properly. You can find it on uunet.uu.net for anonymous FTP. berkeley code is actually pretty portable. it's really not that hard to port berkeley code to non-unix environment. you need to write a set of compatible routines -- spl*(), splx() can be emulated using semaphores, timeout() can be emulated in most operating systems that support watchdog timers of some sort, sleep() (kernel version) can be done via a semaphore or mailbox, wakeup() the same way, perror() and panic() are trivial, cluster mbuf can be emulated if you change the mbuf structure slightly even on systems that lack virtual memory, etc. i'm speaking from my experience... your mileage may vary. hwajin
romkey@ASYLUM.SF.CA.US (John Romkey) (11/07/90)
Well, my experience from watching many people port the Berkeley code is that it's a four to six month effort to get it working. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141
e85rw@efd.lth.se (Ricard Wolf) (11/07/90)
In article <9011061001.AA27908@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes: >Well, my experience from watching many people port the Berkeley code >is that it's a four to six month effort to get it working. Speaking as someone who has just spent a few months porting the berkeley code to a simple microprossesor environment (no virtual memory, no this, no that...), I have to agree ... IT DOES! (:-)) -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+
robinson (Jim Robinson) (11/09/90)
In article <9011052355.AA28967@yuba.WRS.COM> hwajin@yuba.UUCP (Hwa Jin Bae) writes: >>Many people use the Berkeley code as a start. It's an excellent >>protocol engine; its main drawback is that it really really wants to >>live inside a UNIX kernel. It often takes many man-months to port >>properly. You can find it on uunet.uu.net for anonymous FTP. > >berkeley code is actually pretty portable. it's really not that hard >to port berkeley code to non-unix environment. you need to write a set >of compatible routines -- spl*(), splx() can be emulated using semaphores, >timeout() can be emulated in most operating systems that support >watchdog timers of some sort, sleep() (kernel version) can be done >via a semaphore or mailbox, wakeup() the same way, perror() and panic() >are trivial, cluster mbuf can be emulated if you change the mbuf structure >slightly even on systems that lack virtual memory, etc. i'm speaking >from my experience... your mileage may vary. One possible problem is the use of non-int bit fields in the tcp and ip header structures. Pre-ANSI C requires only that unsigned int bit fields be supported by a compiler and ANSI C requires only (*I believe*) signed or unsigned bit fields be supported. Thus, if your compiler does not support, say, unsigned char bit fields, which are indeed used in the BSD code, you will have to do a bit of work to work around this problem. If you are unlucky, as I was, your compiler will *not* complain, but merely generate incorrect code. You will also run into a number of annoying problems if the sizes of ints and pointers on your target machine are greater than 32 bits, since there are several coding practices employed that assume 32 bit pointers and ints. -- Jim Robinson {uunet,ubc-cs}!van-bc!mdivax1!robinson
larryp@sco.COM (Larry Philps) (11/17/90)
In article <1990Nov8.172640.13894@mdivax1.uucp> mdivax1!robinson (Jim Robinson) writes: > >One possible problem is the use of non-int bit fields in the tcp and ip >header structures. Pre-ANSI C requires only that unsigned int bit fields be >supported by a compiler and ANSI C requires only (*I believe*) signed or >unsigned bit fields be supported. Thus, if your compiler does not support, >say, unsigned char bit fields, which are indeed used in the BSD code, you >will have to do a bit of work to work around this problem. If you are >unlucky, as I was, your compiler will *not* complain, but merely generate >incorrect code. > >You will also run into a number of annoying problems if the sizes of ints >and pointers on your target machine are greater than 32 bits, since there >are several coding practices employed that assume 32 bit pointers and ints. >-- >Jim Robinson >{uunet,ubc-cs}!van-bc!mdivax1!robinson Hi Jim! That was a *fun* project wasn't it! (The machine did not have a 16 bit data type, and could not do 16 bit arithmetic!) Originally the compiler only supported int bitfields (8 bytes on that machine), but the standard IP and TCP header structures are both 20 bytes. This is not divisble by 8. Since the machine enforced alignment, it was impossible to reference both the IP and TCP headers of a packet without moving things around. We eventually had to change the compiler to support short bitfields. The BSD code also used an incredibly *portable* method of moving 16 bit quantities around (ie. tcp options) via *(u_short *) cp = something. which unfortunately did not work too well with our 32 bit u_shorts. --- Larry Philps, SCO Canada, Inc (Formerly: HCR Corporation) Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net UUCP: {uunet,utcsri,sco}!scocan!larryp Phone: (416) 922-1937 Fax: (416) 922-8397