Talk:Network socket

Article Quality

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This seems more like a Java tutorial on socket programming as opposed to an article in an encyclopaedia. --121.45.19.162 01:17, 9 November 2007 (UTC)

Where did that Java code come from?--Adoniscik 04:45, 13 November 2007 (UTC)

Obviously, this article was extracted from a book or tutorial: "It also draws on other skills, such as multi-threaded programming, discussed in the next chapter. For now, we'll focus on a simple, bare-bones TCP server that executes as a single-threaded application" o.O "next chapter"??? :O --200.17.143.33 16:32, 14 November 2007 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should we rephrase this?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, in the phrase "The server creates one socket for each client, and these sockets share the same local socket address."

Would it be more appropriate to write "The server creates one socket for each client, and these sockets share the same local IP address."?

Because if I understood correctly, the socket address is composed by IP:PORT, the server will create a new socket for each client, say, 10.0.0.1:10000, 10.0.0.1:10002, etc. This way the sockets created on the server would share the same IP address, but their socket addresses would be different.

Anyone agrees? — Preceding unsigned comment added by Bnegrao2 (talk • contribs) 20:37, 19 January 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Suggestion for rephrasing in the Overview section

I find the description at the beginning of the Overview section a bit confusing: "An Internet socket is characterized by a unique combination of the following :

• Local socket address: ...
• Remote socket address: ...
• Protocol..."

The reason I find it confusing is that it does not distinct well enough between the natural characteristics of any socket, being an end point, meaning having local socket address and protocol, and the special case when a socket is connected to a remote end-point, in which case it has the knowledge of the remote socket address.

Therefore, I would like to suggest the following rephrasing of the first 2 sub-sections of the overview section:

"An Internet socket is characterized by the following:

• Local socket address: Local IP address and port number,
• Protocol: A transport protocol (e.g., TCP, UDP, raw IP, or others). TCP port 53 and UDP port 53 are consequently different, distinct sockets.

A TCP socket that has been connected to another socket, e.g. during the establishment of a TCP connection, will also be characterized by a remote socket address. As discussed in the client-server section below, this is necessary since a TCP server may serve several clients concurrently. The server creates one socket for each client, and these sockets share the same local socket address from the point of view of the TCP server."

Any thoughts? Ronny Weisman (talk) 07:43, 21 January 2015 (UTC)

I think the underlying problem is the vagueness of the term "socket". However, whatever theoretical meaning the term may have with regard to being an endpoint, the overview is correct in that a socket is identified by (protocol + local IP:port + remote IP:port). Indeed, the netstat command mentioned shows exactly that information. Before a connection is established, a host may listen on (protocol + local IP:port), and people call that a socket—but is it? If emphasis is to be given, it should be to show a working socket (five numbers). We could resort to finding what reliable sources say, but terms like this are often used ambiguously. Johnuniq (talk) 08:51, 21 January 2015 (UTC)

A socket can be a UDP socket, or a raw IP socket, therefore not connected to another end-point. In this case it will only have a local address and a protocol, but is is still a socket. Also analogy to electronic socket, being an end-point, either connected to another point or not, makes the network socket concept very clear. In my mind, it shall be emphasized that having a remote address is a special case of a socket usage. Ronny Weisman (talk) 16:50, 22 January 2015 (UTC)

The problem is that after your edit the protocol point started by mentioning TCP which gives a strong suggestion it is talking about TCP sockets. The current text (from before your edit) notes "Only for established TCP sockets." for the Remote socket address. If some improvement were warranted, I think it would involve splitting the text into two parts to avoid clumsy expressions—some sockets have five numbers, and some have three. By the way, you might like to review WP:TP about indenting replies—I put two colons in front of your last comment, and three in front of this comment. Johnuniq (talk) 00:54, 23 January 2015 (UTC)

I agree, the 2nd sub-section that I suggest to rephrase shall better start with: "A socket that has been connected to another socket, e.g. during the establishment of a TCP connection..." removing the TCP from the start of the sentence. What do you say? Ronny Weisman (talk) 13:57, 26 January 2015 (UTC)

Give it a go, but that doesn't sound quite right to me. An established TCP socket is a single thing—the host at each end records information about the socket using five numbers, and it's not thought of as a socket at X connected to a socket at Y. What I was suggesting is that the text would need to be split into two separate parts, one discussing a stateless socket, and one discussing a TCP-style socket. With luck someone will offer another opinion. Johnuniq (talk) 23:40, 26 January 2015 (UTC)

When I first learned about sockets c. 1989, I had only the exasperating documentation which babbled about socket attributes, protocols, and other stuff which did nothing to describe what it is. With much hindsight and experience, it should have said something like this:

A socket is a generalized interface for establishing connections. Connections may be made to the same machine or another machine. The procedure to establish a connection varies depending on the type of socket. Server sockets are available for others to initiate a connection to. Client sockets are associated with a remote socket after they are created. Connectionless sockets manage packet level communication. Connected sockets manage a communication channel which is almost completely oblivious to the underlying mechanisms. All four combinations occur: Server connectionless, server connected, client connectionless, and client connected. Etc.

—EncMstr (talk) 00:14, 27 January 2015 (UTC)

This is a good explanation, and it coincides well with what I'm suggesting: conectionless socket is characterized by local network address and protocol, and connected socket has in addition a remote network address characteristic. In addition, I think we should take into mind the life-cycle of a connected socket: a socket is usually created un-connected, having local network address and protocol, and later on it may be connected, getting the remote network address characteristic. Do you have a vote regarding my modification suggested here? Ronny Weisman (talk) 14:41, 28 January 2015 (UTC)

I read the overview, and my impression is that it is too abstract to be very accessible to the average reader who wants to gain a basic understand of sockets. After I read it a few times, I was able to understand it, I think. This is a description of the semantics of sockets. It is independent of any particular realization in any programming language. But why do we need sockets in the first place? What made them necessary? What problem do they solve? We need them so that a real computer program written in a real application programming language can use communications protocol stacks like TCP/IP. An Application Programming Interface (API) was needed, but first the API needed a design. Sockets represent an abstract design of the API. Sockets are a semantic construct that gives us a design for any real API in any specific language. (Sockets are constructs in the ODP Computational viewpoint, representing the technology-independent constructs of a conceptual design. A real API is a realization of the same semantics in a particular ODP Technology Viewpoint, i.e., a real language.) I think to be understandable, this overview needs much earlier to bring in the realities of the need for a specific API, and how a technology-free design for the APIs was needed first. It should be said early-on that the sockets construct was originally intended for a C-language API to make TCP/IP protocol stacks accessible to UNIX programs written in C. (See Berkeley Sockets.) Other APIs that make sockets available in other programming languages have since used these same design constructs to implement computationally and semantically similar or identical APIs in other languages. The wording of this overview is entirely in the ODP Computational Viewpoint. This is not necessarily a bad thing, but I think just enough info about real language technology and the driving requirement for a TCP/IP API should be brought in very early to make the overview more intellectually accessible to non-architects. Aragorn 23:35, 4 September 2019 (UTC)

External links modified (February 2018)

Hello fellow Wikipedians,

I have just modified one external link on Network socket. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050623074557/http://www.ic.al.lg.ua/~ksv/ to http://www.ic.al.lg.ua/~ksv/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:36, 16 February 2018 (UTC)

Lead improvements

@Kbrose: I'm reviewing these changes. The first paragraph may be getting more technically precise but that's not what we're shooting for in a lead. Neither the new version nor your commented out slightly less new version seem to be an overall improvement on the original. Your work in the second paragraph changes things without offering a clear overall improvement. ~Kvng (talk) 14:26, 21 July 2020 (UTC)

I completely disagree. The old language was atrocious, and made no sense. A network socket is for communication across a network, not within a node, although such sockets also exist as now clearly stated. The language in the analogy was also horrible: "communication between two nodes through a channel being visualized as a cable". Visualized? We don't need to visualize a cable between two devices, just state that it is a cable. And finally, the statement admits that all this was somehow "limited", in that case it shouldn't be mentioned at all. A cable does not have to be "one-to-one", btw., as was apparently implied. Kbrose (talk) 16:38, 22 July 2020 (UTC)

I don't want to get too drawn into this but "most commonly used in the context of the Internet Protocol" is a bit of a problem because it's actually TCP or sometimes UDP, not IP. Also, I would say "remote" rather than "foreign". The current article mentions female connector in the Use section and not in the lead—that seems desirable since the lead should focus on what a socket is and the analogy confuses that. Johnuniq (talk) 00:22, 23 July 2020 (UTC)

Resolved. Kbrose (talk) 01:18, 23 July 2020 (UTC)

Thanks Kbrose. The new stuff is a clear improvement. ~Kvng (talk) 15:49, 26 July 2020 (UTC)