Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 17 Apr 2017 08:34:46 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-net@freebsd.org
Subject:   Re: Small socket programming question
Message-ID:  <c4886459-0f56-5d49-0cf0-a3616432bc03@denninger.net>
In-Reply-To: <83113.1492398076@segfault.tristatelogic.com>
References:  <83113.1492398076@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]

On 4/16/2017 22:01, Ronald F. Guilmette wrote:
> Sorry, I -think- I know that answer to this question, but
> I'd prefer to ask and make sure, in case I have misunderstood
> things.
>
> I am aware that for any open socket, the kernel sets aside
> some amount of buffer space for that socket.  (And yes, I
> *do* also know that the specific amount set aside may be
> programatically controlled.)
>
> So anyway, let's say that I have either a RAW or UDP
> (datagram) socket open and my program is running on a
> nice fast machine, but it's outbound connection is via
> a rather slow link.  So if my program writes and writes
> and writes to this socket, eventually, I'll have used up
> all of the buffer space that the kernel has associated
> with the socket.
>
> My question is just this:  What happens then?  Will further
> writes to the socket block until some more packets get sent
> out, you know, so that there is once again room in the
> outbound buffer that's associated with this socket?  Or will
> I instead get some error back from the call to write(), like
> for instance EAGAIN or ENOSPC or maybe ENOBUFS?
>
> Or does the kernel in such cases just silently discard
> one or more of my precious outbound packets without even
> telling me?  (I guess this is my way of asking whether or
> not the FreeBSD kernel may, in some cases, itself be a
> source of "packet loss".)
>
> Thanks in advance for any & all enlightening replies.
What happens depends on whether you have set the socket to nonblocking
or not.

If it is set to blocking then the call should block until space is
available. If it is set to nonblocking then you get a -1 back (instead
of the number of octets actually written) and errno is set to indicate
the reason.  EAGAIN should be returned if the call would have blocked if
the socket was set to blocking mode (the output buffer is full); you can
also get ENOBUFS, but that is supposed to mean system buffer congestion
(rather than your *specific* socket's buffer set being full.)

Note that you generally need to use sendto and friends instead of write
for connectionless operation since it specifies a destination and option
flags (in other words you don't need to call connect), and write()
doesn't return the full set of error conditions that sendto does.

A kernel (FreeBSD or otherwise) may be *forced* to discard data should
it run out of buffer space on the receive side and in that instance
there's nobody to notify since the cause of the overrun is not on the
local machine.  That's the "least bad" outcome for that involuntary
situation. But in the event that a local process *would* cause a buffer
overrun the kernel will instead return an error to the calling process
and *not* toss the data on the floor.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
\0X0@=0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
161218194535Z
211217194535Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
͍fd`1ie6";fSz`5¹/?{=Ӵowjħ_fnӴMG\ҢҖ4ib}>@mJo&mM;
Q9U cj]p퐆W.2E=
^¢tzĄ'5i7_`~#dY
`]R]N%R}EXzqV@[oN	T>5AwYˡA"\v&YG]+($p:M,T?=mJkMљg*ym
L!J[./d׷?W^LysD'1
+V'~{-SSX=q-f=%&V<m4BeSet|
l2m 6iO{wv
+aHXˈ5=~é*C!?uJr3tb'3`Oe)üLxt&3N526llU
.|Cp[l?007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U/Zi
0GhG0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
b%X%gwq	
ɁэrK[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7jGj9铚~3f2AʺN	k~@vz^j(>ͺyh2y{/9}4.45#S|<fW!.,Bss*Q+h=}l@	"q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1򹿈nZ5TuPvW|#G+	DZpI7S'n0 haGa@vZ	e|]Cu+))vRyY100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	`HeM0	*H
	1	*H
0	*H
	1
170417133446Z0O	*H
	1B@)%8pI;5EHلU"DϓYJ\
]jz2ۜoٲ9Bx0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	*H
[6c&T{nfحS>3`mHPʼmOzi]Qx+W!Mp)UZ%[p>&
iě6>LzN~iONExWo踁_ia`R$SR7rx@vl=1
7
ڀz=Y_Ɣ2Bd4m=X2>@~`WOY(_PPcpm]on>5*$9R=\.cT}oh}Pta>|Gr ZKXUUniznj(>|:,5INȇuj3"W=&	aVkLy֫=jWϨk*Ed&|Fn.Wh䦫'{_ dIe~]nd/2p''s҉4)ccg)h]z
A`_im<0`lt̤+_l~F nl

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4886459-0f56-5d49-0cf0-a3616432bc03>