Date: Tue, 10 Oct 1995 20:25:33 -0400 From: dennis@etinc.com (dennis) To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: IPX Message-ID: <199510110025.UAA02108@etinc.com>
next in thread | raw e-mail | index | archive | help
>> >If you are talking about serving NetWare clients, then you are talking >> >about responding to GetNearestServer() calls from the clients, at the >> >very least to proxy them, since only a server on the same segment can >> >respond directly. >> >> A true IPX router manages a network routing table and proliferates server >> information with other routers in the cloud. The information provided in >> response to a "GetNearestServer" call is a server name and a net, thus >> implying routing, not bridging. Routers route to nets in a very similar >> manner to IP routing. SPX is more analogous to TCP.....there is no impact or >> significance of windows or other aspects of SPX at the IPX routing level. >> Our IPX router is conformant to the "IPX Router Specification" Novell part >> number 107-000029-001. > >The point being that if you implement an IPX server, presumably you will >need to implement reponses to GetNearestServer(). > >If you implement it on top of an existing IPX (like yours), then you >will need to use an ioctl() to retrieve the information to respond via >proxy (unless you illegally copy login.exe from a real Novell server). > > >All I'm saying is that your IPX implementation is sufficient (you >claimed that it wasn't usable as a general kernel extension because >it wasn't appropriate for thistype of use). > Oh......I wasn't exactly sure where you were coming from. Another obstacle is that there is no way to pass a packet to our IPX handler, and if you added one you really would want to re-write the entire encapsulation scheme because we really don't have the proper procedure to do it as we're only concerned with building packets for RIP and SAP in very low volumes. What I was saying is that it was really designed to do something else....like route packets fast....and shouldn't be used for a client or server implementation. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510110025.UAA02108>