Talk:Berkeley sockets

From Wikipedia, the free encyclopedia

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

Contents

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

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)
I've done a bit more work on the article. More to come, later. - James Foster 00:57, 27 September 2005 (UTC)

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

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)

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

The tutorial needs some cleanup and should be wikified --vineeth 08:14, 10 February 2006 (UTC)
The tutorial has been plagiarised from this website. I've reverted it. - James Foster 10:57, 10 February 2006 (UTC)

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


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


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)

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

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)

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

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

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

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)

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)
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)