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
This is a cryptographically signed message in MIME format.

--------------ms050707010509070007030304
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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.

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

--------------ms050707010509070007030304
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl
bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND
dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9
07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07
trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE
hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv
TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST
p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ
RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl
klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1
PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t
NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB
BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w
6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES
a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8
d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx
v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH
Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ
HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe
atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL
G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA
s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl
m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm
R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx
KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv
cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww
GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl
bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MTcxMzM0NDZaME8GCSqGSIb3DQEJBDFCBEDVKSWn
/fUGOHBJGInZO/kevpc12QtFmEjZhL9Voc7hIkTj0s+T7VlKXIQaCpBdarB6mzLP25wGkqVv
2bI5QngVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT
B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM
QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT
eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT
MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg
U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B
CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAkFs2pxvyBbRj
JuKg4eZUe27TyWYWHwLYrVOUvd8RPjOTYG1IEFDNyrxt/LJP9gWX1//5eoPgaV26UXiUK1ch
q01w8ilVWgSJJeJbcD6YJvvYCmnEm+2a5e82o7k+TA/7h3oUTrF+oWndT07aRdTo4toIpad4
qPju18xXvm/64ui4gV8P5mnVCGG/YLJSECQWU1L+N9ByeOJABeyIdq+25WwEgT0x0Aoakzca
CqK1ttqAej3NWQDLf1/lxpTkMpdCZDScHqxtPVgyPsP4f57ukEB+/WALE1ffT8zHWSjgwNvH
0V9QHre2ylATrfZjcMCco21db4uAjaalbozyPvg1KsUkOfRSALjQPQa5XC7eY1R9m61vnoFo
fVB0YRQ+3wHlfKtHcvXIIFpLpVhV3dMM2AMQVaWEjW5pem67pGq3xig+uo58rKE6xuUsNUnq
nH+Hiu/qBgCWlJ1OyIewFpKFpBB1ajMisOKK6VeRyT0mzAlh7/RWa0x51quatz3gaqKFA1fP
qKLUAGuzkNzyKkXCZATw/qgmfEa1+W4uodrHV4poDOSmq+gne1+N+9ggZLvRB0n9umURfl1u
ywNkL/wyhHACJydz0ok09yljY2eC/CnUaF16zAr9qUFgX2lt8sKP3zwV4DBgAMYQbHTMpCvz
X7f4bI70frJGIIj1jNwWbmwAAAAAAAA=
--------------ms050707010509070007030304--



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