Talk:Berkeley sockets

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

from talk:Accept (computing routine)

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)[reply]

Where are descriptions of send, recv, sendto and friends?

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)[reply]

I've done a bit more work on the article. More to come, later. - James Foster 00:57, 27 September 2005 (UTC)[reply]

Sockets variations.

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)[reply]

I've noticed someone redirected Berkeley socket interface here. That's good. I believe I will start re-writing this soon (1-2 weeks). I believe I'll redirect this to socket (computer science) (it doesn't exist yet, I'll write it). Maybe I'll write before and then merge, who knows. Anyway, I will somewhat link this page and Winsock togheter (as in a'hub'). I also believe I'll scrap this layout completely.MaxDZ8 18:57, 13 November 2005 (UTC)[reply]

The tutorial...

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)[reply]

The tutorial needs some cleanup and should be wikified --vineeth 08:14, 10 February 2006 (UTC)[reply]

The tutorial has been plagiarised from this website. I've reverted it. - James Foster 10:57, 10 February 2006 (UTC)[reply]

UDP socket server using listen(..)

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)[reply]

This is opaque

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)[reply]

I agree the article could be improved (for example listing the header files doesn't seem too useful in this context) but in my opinion, details like the few you're discussing should not be covered here. It seems better to have this is TCP/IP or network protocols or Unix pages.
This must be opaque. It's abstraction.
MaxDZ8 talk 08:19, 20 March 2007 (UTC)[reply]

gethostbyname and gethostbyaddr

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).[reply]

I think, that we should use getaddrinfo () and getnameinfo () instead of this two functions. —Preceding unsigned comment added by 83.21.67.54 (talk) 08:06, 13 October 2007 (UTC)[reply]

Clarification needed in "Blocking vs. nonblocking"

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)[reply]

SOCK_SEQPACKET

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)[reply]

Summary of this article in the Internet socket article

I have sumarized the functions provided by Berkeley sockets API in the Implementation issues section of the Internet sockets article. Someone, please check that my formulations are okay. Mange01 (talk) 17:59, 1 June 2008 (UTC)[reply]

Your text with my commentary:

socket() creates a new socket of a certain socket type, identified by a 32 bit socket descriptor, and allocates system resources to it.

Nobody guarantees that file descriptors are 32 bits. They're int. Haven't seen 64-bit int yet? Some day... And "file descriptor" is the correct term. A socket is a type of file[1]; sockets are in the same integer namespace as other file descriptors. Only Windows gets this wrong. Should non-standard terminology be used when writing about socket programming, because someone failed to correctly implement the standard we're writing about?

bind() is used on the server side, and associates a socket descriptor with a socket address structure, i.e. a specified local port number and IP address.

You can also bind() before connect()ing to request a specific originating port (which is used by some unix programs to connect from a privileged port following the "root on one host trusts root on the other host" security model) or a specific originating address (which has been used by people who want a remote host to see a specific incoming IP address - usually with a vanity domain as its reverse DNS).

connect() is used on the client side, and assigns a free local port number to a socket descriptor. In case of a TCP socket, it causes an attempt to establish a new TCP virtual circuit.

Does anybody really use the phrase "virtual circuit" in the real world?

accept() is used on the server side. It accepts a received incoming attempt to create a new TCP virtual circuit from the remote client, and creates a new socket associated with this virtual circuit.
send() and recv(), or write() and read(), or recvfrom() and sendto(), are used for sending and receiving data to/from a remote socket.

This would be the place, if any, to mention that read() and write() are broken with respect to sockets.

close() causes the system to release resources allocated to a socket. In case of TCP, the virtual circuit is terminated.

--tcsetattr (talk / contribs) 20:36, 1 June 2008 (UTC)[reply]

Thnx for your helpful comments! I realize that my knowledge is limited on this topic. Please feel free to solve these issues in the Internet socket article. Keep in mind that the "Implementation issues" section is a summary. The details should be discussed in this article.

In computer networking literature we say "virtual circuit", "circuit", "virtual connection", "connection", "TCP session" and "byte stream", all of them referring to almost the same thing. Which do you prefer in this context? Mange01 (talk) 23:06, 1 June 2008 (UTC)[reply]

In most cases I'd just say "connection", or "TCP connection" if there's any uncertainty. But when defining what "connect" does, it would be sort of unhelpful to say "connect creates a connection", so "virtual circuit" isn't necessarily bad. I just wonder if it's an understandable term to the target audience (whoever that is). Linking to the virtual circuit article would help. Looking through a few RFCs (a form of "networking literature" containing more Internet jargon than telco jargon) I find "connection" a lot more often than "circuit". --tcsetattr (talk / contribs) 23:36, 1 June 2008 (UTC)[reply]

Too much detail

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)) —Preceding unsigned comment added by 201.59.234.143 (talk)

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)[reply]

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)[reply]

close(i32Res)?

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)[reply]

AF or PF

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)[reply]

Added a new section for this purpose. Kbrose (talk) 20:23, 19 December 2008 (UTC)[reply]

thanks, —j.engelh (talk) 00:54, 25 December 2008 (UTC)[reply]

Code samples

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)[reply]

inet_pton and INADDR_ANY

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: ^[1] — Preceding unsigned comment added by Lbartnik (talk • contribs) 14:50, 31 May 2011 (UTC)[reply]

References

^ http://www.kernel.org/doc/man-pages/online/pages/man3/inet_pton.3.html

Terminating section not quite accurate, specific to TCP

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)[reply]

Dual-stack examples

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)[reply]

"Raw Sockets" section needs citations or deletion.

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)[reply]

[1] ttp://www.kernel.org/doc/man-pages/online/pages/man3/inet_pton.3.html

[1]