Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any major differences when we talk about "socket programming" compared to "network programming"?

Are there some topics that cover "network programming" but not "socket programming"?

share|improve this question
up vote 18 down vote accepted

Socket programming (at least as the term is normally used) is programming to one specific network API. Sockets support IP-based protocols (primarily TCP and UDP)1.

Network programming can be done using various other APIs. Windows has a number of protocol-independent APIs such as the WNet* and Net* functions. Older versions of Windows also used NetBIOS/NetBEUI (NetBIOS End User Interface), and most supported (and probably still do) IPX/SPX (an old Netware protocol).

Most current network programming, however, is done either using sockets directly, or using various other layers on top of sockets (e.g., quite a lot is done over HTTP, which is normally implemented with TCP over sockets). TCP/IP and UDP/IP (as well as a number of other IP-based protocols) are done primarily via the sockets interface. In theory, other programming interfaces could be used, but in practice sockets seem to be sufficient, so there's not a lot of interest in replacing it. I should, however, mention that Windows sockets (WinSock) have quite a few extensions that are more or less unique to Windows. I suppose it's open to some argument whether code that uses these extensions really qualifies as "sockets" code or not -- they are extensions based on the same concepts, but code that uses them isn't normally portable to other systems. I guess whether it qualifies as "sockets" or no depends primarily on whether you think of sockets more as a concept, or a very specific set of functions, parameters, etc.

Edit (in reply to comment):

It's a bit hard to say whether "knowing sockets" implies knowing "everything" about TCP and UDP. Let's consider just one small piece of things: one typical demo program for sockets is creating a client/server chat program. The client connects to the server, and when the user on one client types something, it gets forwarded to the other clients that are connected to the same server. Each client displays what comes in from the server, and lets the user type in messages to be sent to the other clients.

At the same time, consider what a "real" chat program like AIM, Windows Messenger, iChat, etc. involves. To handle not only text, but voice, video, file transfers, groups, lists, etc., a typical program probably involves a dozen different standards, including such things as SIP, STUN, TURN, RTCP, RTP, XAMPP, mDNS, etc.

IMO, somebody who "knows sockets" should be able to code up the first (demo-level, text-only) chat program in a few hours without spending much time in help files (and such) doing research. Unless they claimed at least some prior experience working on a "real" chat program, I wouldn't expect them to even know which RFCs/standards applied to such things though.

The same applies in general: given the number of RFCs (and various other standards) that get applied to all the different things people do over networks, it's unreasonable to expect anybody to have memorized all of them. Nonetheless, if you have a set of requirements for something that you'd expect people to be able to handle in a "local" program easily, just adding "over the network" as a requirement shouldn't normally add a tremendous amount of difficulty (though dealing with issues like network latency might).

1 Sockets on Unix also support Unix-family sockets, but these are (at least normally) used for intra-machine IPC, not networking. There are also literally dozens of other protocols for such things as router management that sockets don't really support (beyond raw sockets allowing you to build and send arbitrary packets).

share|improve this answer
Thanks, now this is an answer worth upvoting. :-) So, can I conclude that when I say I know socket programming, it means dealing "everything" with TCP/UDP, only? I need to know everything about TCP/UDP? – TheIndependentAquarius Sep 20 '11 at 9:04
@AnishaKaul: See edited answer. – Jerry Coffin Sep 20 '11 at 17:11
@JerryCoffin: Possibly worth noting that sockets are a subset of IP-based protocols too. There are things like ICMP/IP that aren't covered by sockets either. – Matthew Scharley Mar 4 '14 at 10:53

"network programming" will require some networking technology - for example, RPC. Sockets (most likely you mean BSD sockets) are an example of such technology. So "socket programming" is a subset of "network programming".

share|improve this answer
@Anisha Kaul: Okay, RPC programming is network programming (a subset thereof) and one important RPC concept is a so-called string binding - see You don't need that thing when programming BSD sockets. – sharptooth Sep 20 '11 at 7:58
@Anisha Kaul: No, "all possibilities" is a huge list. I'd name some widely used - Java RMI and .NET Remoting are good examples. – sharptooth Sep 20 '11 at 8:30

Yeah, it's true that network programming requires networking technology while on the other hand socket programming is a subset of network programming. Most current network programming is done either using sockets directly, or using various other layers on top of sockets.

share|improve this answer
this does not seem to add anything substantial over what was already posted in prior answers – gnat Mar 4 '14 at 16:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.