Talk:Berkeley sockets

message: Why on earth does an obscure Unix library call merit an encyclopedia article?  Maybe the library as a whole should, and it can contain links to man pages for each function, but this is so out-of-context I can't imagine it being useful. --LDC
I've moved it into a new page about the library as a whole.  Fill it in as necessary. --Damian Yerrick
I'm going to re-arrange the descriptions of each function to be more readable (in my opinion), by listing the parameters in point-form. Discuss, and revert if it is decided that it's not better this way. - 129.78.64.101 03:32, 25 May 2005 (UTC)
replies: text: You're right, this article isn't nearly "finished". It doesn't really need to describe the entire Berkeley sockets API, but the most commonly used functions would be nice. I might find time to do some work on the article within the next couple of weeks. - James Foster 13:40, 14 September 2005 (UTC)
replies: text:  I've done a bit more work on the article. More to come, later. - James Foster 00:57, 27 September 2005 (UTC)
thread_title:  from [[talk:Accept (computing routine)]] 

message: I was expecting computer sockets to be in their own article, instead, I find out that [socket] has only a small fraction of informations regarding [Computer sockets].
I believe this is quite bad. This shall really be linked with this page, maybe with a disambiguation.
I find very difficult someone will write 'Berkeley sockets' for the API, not to mention the fact win32 is a popular platform so we may also take winsocks in consideration.
I plan to be able to spend some time on this. Can you give me any suggestions? MaxDZ8 16:44, 21 October 2005 (UTC)
thread_title:  Sockets variations. 

message: Originally located in the disambiguation page, I believe it's better to put it here. I hope it's work in progress but it's too much to scrap it over.  MaxDZ8  talk 18:43, 9 February 2006 (UTC)
replies: text: The tutorial needs some cleanup and should be wikified --vineeth 08:14, 10 February 2006 (UTC)
replies: text:  The tutorial has been plagiarised from this website. I've reverted it. - James Foster 10:57, 10 February 2006 (UTC)
thread_title:  The tutorial... 

message: why is there a call to listen in the UDP server example? Listen is only used to put connections on a backlog. UDP is a connectionless protocol.
willem
You are right. Stevens: "The listen function is called only by a TCP server [...]".
Removing it.
(The rest of the examples should be reviewed due to this blatant bug, of course.)
JöG 14:02, 28 October 2006 (UTC)
thread_title:  UDP socket server using listen(..) 

message: If you look at the article you will find explanations like to bind you call the bind() function.  This is not really giving any explanation about what sockets really are.  What does the computer do in response to a bind?  How does the packet coming in get processed from the point of the network interface to the data delivered to the application?  Where is there any mention of a Unix socket file?  What about the glorious deception that lets a local process act like a remote process in the grand scheme of things? Kd4ttc 16:27, 19 March 2007 (UTC)
thread_title:  This is opaque 

message: The gethostbyname and gethostbyaddr functions are not part of the Berkeley socket API. —The preceding unsigned comment was added by 15.227.137.70 (talk) 16:51, 1 May 2007 (UTC)
thread_title:  gethostbyname and gethostbyaddr 

message: Hi, I know nothing about networking, and I think this part will be confusing for others, as it was for me. The problem is that it cites a disadvantage for blocking sockets, but it provides no reason why one would ever want to use one, and therefore, why they even exists at all...
Could someone please add info to that section?  Althena (talk) 14:14, 27 January 2008 (UTC)
thread_title:  Clarification needed in "Blocking vs. nonblocking" 

message: If I've understood correctly, SOCK_SEQPACKET doesn't correspond to any underlying transport mechanism (like TCP or UDP for DGRAM and STREAM respectively) and therefore cannot usually be used. This would be very good to mention - can someone who is more sure of the facts please add something to this effect to the description of socket() ?  —Preceding unsigned comment added by 85.112.166.110 (talk) 17:32, 3 March 2008 (UTC)
thread_title:  SOCK_SEQPACKET 

message: Is this a wiki page or a man page? do we need so much code or just a simple explanation of what it does?
:Yes, we do need this kind of detail. This article need not to be too simple just because 99% of the Wikipedia is. (09:02, 23 September 2008 (UTC)
replies: text: I'm with the OP on this one. I don't think API documentation (covering even single functions and parameters!) belongs on Wikipedia. Why not scrap all this bulk and place a link to the official documentation? 80.138.242.166 (talk) 14:49, 6 May 2009 (UTC)
replies: text: Principally you are right. Wikipedia should mainly be theoretical - practical how-to information do not deserve own articles, but may be used as examples inside other articles. However, if this article did not exist, people would put a huge section of technical details in the end of the Internet socket article, which is less detailed, and written for a larger audience. Of course, that is an option, but it would result in a very long merged article. I prefer the current solution, where this article can be seen as an extension to the Internet socket article. Mange01 (talk) 21:29, 6 May 2009 (UTC)
thread_title:  Too much detail 

message: Is the call to close(i32Res) in Client code correct? i32Res is the return value of inet_pton, which does not return a socket, but a status, as far as I know.  —Preceding unsigned comment added by 77.206.111.44 (talk) 21:30, 13 December 2008 (UTC)
thread_title:  close(i32Res)? 

message: Changelog messages indicate “and yes, AF_INET and PF_INET are supposed to be inconsistent” (Freqsh0) and “change PF_INET to AF_INET in text when it does not relate to the socket function parameter” (Kbrose). Please elaborate on why one should be chosen over another if, at least, most contemporary systems define them to be the same, and which should be used in which case. —j.engelh (talk) 19:24, 19 December 2008 (UTC)
replies: text: Added a new section for this purpose. Kbrose (talk) 20:23, 19 December 2008 (UTC)
replies: text: thanks, —j.engelh (talk) 00:54, 25 December 2008 (UTC)
thread_title:  AF or PF 

message: Kbrose, why do you keep reverting quite legitimate edits in the code samples which fix the obvious issues with them? --Bełamp (talk) 16:43, 23 March 2011 (UTC)
thread_title:  Code samples 

message: INADDR_ANY is defined as:
linux/in.h:#define      INADDR_ANY              ((unsigned long int) 0x00000000) 
netinet/in.h:#define    INADDR_ANY              ((in_addr_t) 0x00000000)
which when passed to inet_pton is resolved to a NULL pointer causing a segfault (at least with my: glibc-2.12-1.7.el6_0.5.x86_64)
The manual page does not say a NULL pointer can be passed as the second argument: http://www.kernel.org/doc/man-pages/online/pages/man3/inet_pton.3.html  — Preceding unsigned comment added by Lbartnik (talk • contribs) 14:50, 31 May 2011 (UTC)
thread_title:  inet_pton and INADDR_ANY 

message: From the section on Terminating Sockets: "When the close() system call is initiated by an application, only the interface to the socket is destroyed, not the socket itself. It is the kernel's responsibility to destroy the socket internally. Sometimes, a socket may enter a TIME_WAIT state, on the server side, for up to 4 minutes.[6]"
The TIME_WAIT state is specific to TCP; I believe this paragraph is entirely discussing TCP. The phrase "on the server side" is wrong: According to IETF RFC 793, the socket which enters the TIME_WAIT state is the socket which first emitted a FIN segment. In BSD sockets, in my experience, this is typically the first socket to invoke shutdown(SHUT_WR) or close() - not necessarily the server (HTTP is an occasional counter-example.) Even allowing for loose jargon, the distinction between 'client' and 'server' is also not applicable here: Both client and server sockets are in the ESTABLISHED state, and are no longer distinguishable. Thus, "on the server side" should be replaced with something like "on the side of the host initiating the clean socket close operation" (or "on the side of the host emitting the FIN segment" if we're admitting that we're solely discussing TCP.)
The 4 minutes number is twice the TCP MSL, and is configurable, though I think the 2xMSL == 4min default is the most commonplace.
Recommend either removing this paragraph entirely (as it discusses an aspect of TCP, not BSD sockets in general) or correcting the above and citing RFC 793 (see the state diagram on page 23, http://www.ietf.org/rfc/rfc793.txt)  — Preceding unsigned comment added by Lyngvi (talk • contribs) 06:43, 2 December 2012 (UTC)
thread_title:  Terminating section not quite accurate, specific to TCP 

message: I just noticed that the examples are IPv4-only. Wouldn't it be better to show dual-stack examples here? I can imagine new developers copying these examples as a starting point, and these days doing IPv4-only would be a mistake...
--Sjmsteffann (talk) 09:57, 22 November 2013 (UTC)
thread_title:  Dual-stack examples 

message: It's nonsense anyway. Ping and tracert (which is just an extension of ping) do indeed use raw sockets because there's no BSD abstraction specifically for ICMP, but that's about the only thing in this section worth mentioning. Raw sockets are not 'more powerful' than TCP or UDP sockets. They're sure as hell not 'most detailed'. They have no implicit detail at all: hence the name. 
This statement is vacuous and nonsensical:
"Most operating systems support raw sockets, due to its ease of implementation."
This one is outright bullshit:
"raw sockets support was intended to be available only on computers used for developing Internet-related technologies"  — Preceding unsigned comment added by 98.247.50.244 (talk) 19:40, 5 June 2014 (UTC)
thread_title:  "Raw Sockets" section needs citations or deletion.