From owner-freebsd-hackers Mon Jan 29 11:12:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22953 for hackers-outgoing; Mon, 29 Jan 1996 11:12:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA22943 for ; Mon, 29 Jan 1996 11:12:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04198; Mon, 29 Jan 1996 12:09:31 -0700 From: Terry Lambert Message-Id: <199601291909.MAA04198@phaeton.artisoft.com> Subject: Re: NetBUI and/or IPX routing? To: jhay@mikom.csir.co.za (John Hay) Date: Mon, 29 Jan 1996 12:09:31 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199601270518.HAA09078@zibbi.mikom.csir.co.za> from "John Hay" at Jan 27, 96 07:18:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > A "GetNearestServer" from "IPX client" will elicit a response both > > from "FreeBSD Router" and "NetWare Server2". > > No it should not. Server1 isn't the nearest anymore, so the router should > not respond to a GetNearestServer SAP request from the IPX client. Ah. Here is the problem. A GetNearestServer request is not propagated past the local subnet. It is a special case broadcast NCP. If a router replies, it is not because it is non-local, it's because the router is replying on behalf of the server. That is, the router is replying, Server1 is not replying through the router. Note that if enough clients were already attached to Server2, then Server2 would ignore the request. So it's an error for the router to truncate replies based on the existance of a local server with a smaller hop count. It is more important that the client get a connection than the connection actually be the smallest posible hop count. > > A local server is preferaable to a routed serve because of negotiated > > packet sizes through routers dropping to 512. > > A bigger problem (performance wise) is the extra hop that is incurred for > NCP. Burst mode isn't the whole answer to that. Having 1/3 the packet size is a bigger hit than the additional latency of the multiple hops. I agree that packet-burst only minorly helps latency. It is a fixed window single response protocol. I dislike it immensely, since its intent is to allow a single client to monopolize the wire to improve benchmark performance. On a big net, it causes problems instead of solving them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.