From owner-freebsd-net Thu Aug 27 18:43:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20458 for freebsd-net-outgoing; Thu, 27 Aug 1998 18:43:05 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA20442 for ; Thu, 27 Aug 1998 18:42:55 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id VAA11467; Thu, 27 Aug 1998 21:42:01 -0400 (EDT) (envelope-from wollman) Date: Thu, 27 Aug 1998 21:42:01 -0400 (EDT) From: Garrett Wollman Message-Id: <199808280142.VAA11467@khavrinen.lcs.mit.edu> To: net@FreeBSD.ORG Cc: kirk@McKusick.com Subject: Puzzled over sosend's handling of pre-prepared mbufs... Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In looking over mbuf handling for TCP some more, I noticed a puzzling omission. When sosend() is handed an mbuf chain rather than a uio, it makes no effort to check whether the chain would actually fit within the socket buffer limits. It simply calls pru_send() with the mbuf chain, which -- in TCP's case -- just passes it to sbappend() also without making any sort of check. The only client of this interface, NFS, also makes no attempt to check the socket buffer capacity. Is this reasonable? I would rather see NFS obey the same buffering model as everything else; that will make life much easier when the underlying buffer mechanism changes. In this case, that would mean that the process making the NFS request would get blocked rather than ``overrun'' the buffer. (I put ``overrun'' in quotation marks since there is no physical limit on socket buffer lengths, just a logical/administrative one.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message