From owner-freebsd-net@freebsd.org Mon Apr 17 13:34:48 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6BEDD41E49 for ; Mon, 17 Apr 2017 13:34:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 88175F4B for ; Mon, 17 Apr 2017 13:34:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 2510F602B7 for ; Mon, 17 Apr 2017 08:34:47 -0500 (CDT) Subject: Re: Small socket programming question To: freebsd-net@freebsd.org References: <83113.1492398076@segfault.tristatelogic.com> From: Karl Denninger Message-ID: Date: Mon, 17 Apr 2017 08:34:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <83113.1492398076@segfault.tristatelogic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050707010509070007030304" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 13:34:48 -0000 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 /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--