TCP vs Sockets: A request for elucidation! (test your knowledge)

[jackthechemist]

Greetings,

So, I've studied sockets, and studied TCP, and enjoy a beginner-intermediate understanding of each. However I desperately need clarification regard some fundamental concepts. Any help would be greatly appreciated:

1) Do sockets implement TCP? When I uses a socket to send data to another computer, are the computers using TCP or is it my responsibility to implement it (ie write the program such that the methods of the sockets mimic the rules dictated by TCP) I am confused.

2) I've read most of the RFC regarding TCP. It mentions a 'user interface'. Further, it specifies various TCP 'commands'. If MSN / Pidgin is using TCP, how could I use say C / Python to send 'TCP commands' and if MSN / Pidgin is merely using sockets to do this and the OS is responsible for TCP implementation then how can i send say a TCP header (consisting of 1s and 0s) manually? I know how to manually send HTTP requests manually, how can i do this with TCP?

Before you respond, please note, I'm not a programmer, I'm a chemist (I just happen to love computers) so for my sake, try to answer accordingly! ^_^

Jack

[BestJewSinceJC]

Greetings,

1) Do sockets implement TCP? When I uses a socket to send data to another computer, are the computers using TCP or is it my responsibility to implement it (ie write the program such that the methods of the sockets mimic the rules dictated by TCP) I am confused.

Jack

Read this and look at the section on "Socket Types". To answer your question, yes, some types of sockets use TCP. But just because something is a Socket does not mean it has to use TCP. Being a Socket really just means it is a bi-directional connection where you can send data from one machine to another. The order of the data's arrival is not guaranteed due to network properties and that's where TCP comes in. From my understanding, it basically takes your data and forms it into packets where it includes information that it can later use to make sure your data arrives in the correct order to whatever process you sent it to. The services necessary for TCP have already been implemented (and are probably made available by the OS). I'm not positive whether it is actually the OS that makes them available, but it doesn't really matter IMO. The main point to know is that TCP is a protocol that BOTH endpoints must somehow implement in order to guarantee a correct order delivery of data to the receiving process/application. And that someone before you has already implemented it somewhere.

[Fest3er]

Greetings,

So, I've studied sockets, and studied TCP, and enjoy a beginner-intermediate understanding of each. However I desperately need clarification regard some fundamental concepts. Any help would be greatly appreciated:

1) Do sockets implement TCP? When I uses a socket to send data to another computer, are the computers using TCP or is it my responsibility to implement it (ie write the program such that the methods of the sockets mimic the rules dictated by TCP) I am confused.

2) I've read most of the RFC regarding TCP. It mentions a 'user interface'. Further, it specifies various TCP 'commands'. If MSN / Pidgin is using TCP, how could I use say C / Python to send 'TCP commands' and if MSN / Pidgin is merely using sockets to do this and the OS is responsible for TCP implementation then how can i send say a TCP header (consisting of 1s and 0s) manually? I know how to manually send HTTP requests manually, how can i do this with TCP?

Before you respond, please note, I'm not a programmer, I'm a chemist (I just happen to love computers) so for my sake, try to answer accordingly! ^_^

Jack

A socket by itself has limited value; they're best used in pairs. So start with an image. Picture a female-to-female RJ-11 (phone wire) adapter; this is an analog of a wired network. The sockets (imagine that) are equivalent to networking sockets. The RJ-11 jacks are the API (programming interface) to use the sockets and communication. Now get your hatchet and chop the adapter in half; you now have the analog of a wireless adapter. :)

A network socket is merely something you 'plug' a program into. But you don't have a dedicated, wired circuit for each possible combination of socket pairs. It is, in essence, a virtual circuit, as are all things in the world of bits, nibbles and bytes. The underlying protocols know how to contact the other socket in the 'pair' you've selected because you've told them what you want to connect to, and how.

There are many kinds of socket connections. The two main ones are:

• TCP - a fairly reliable protocol that does its best to ensure that no data are lost between the two sockets. It is connection-oriented; positive communication and setup is needed between the two sockets before data can be transferred. It will retransmit packets as needed. It will use counters, checksums and 'sliding windows' to assure error-free data transmission.
• UDP - a connectionless protocol. Packets are 'blindly' sent to the other socket. If the remote gets the packet, great. If not, too bad; the two programs would need to implement, you guessed it, a protocol to detect, request and retransmit lost packets. It's still called 'unreliable', even though UDP packets can very often be shoved across today's internet without loss.

These two were good for some years. But novel uses of the internet, such as realtime voice and video communication, have made newer protocols necessary. These protocols (I believe SCTP is one of them) try to guarantee a certain minimum transmission rate such that the data streams across smoothly and is played by the recipient, in realtime, at the same rate the sender sent it.

Sockets do not implement protocols. Just as you connect to a socket, a socket connects to the protocol you requested. Otherwise, it would be akin to saying that the phone jack on your wall implements the phone system.

If you are a certified auto-sado-masochist, you can write your own version of TCP. The rest of us pretty much use existing libraries. :)

Suppose you have a LAN in your lab. Your executives have a LAN for themselves. Accounting have a LAN. With routers connecting those LANS, you are part of a small internetwork. Now add a router to the rest of the world; you have become part of the largest internetwork, the Internet.

These internetworked LANs use the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite. For simplicity (some will call it a gross over-simplification), I'll say that IP is the lowest protocol; it handles knowing how to find and talk to all other nodes on the internetwork. TCP talks to and communicates over the IP protocol. To carry it further, HTTP talks to and communicates over TCP. Your web browser talks to and communicates over the HTTP protocol.

If you have some remote specialized lab equipment, you might implement a custom protocol to control it from your main lab, such that your desktop computer controls all parts of an experiment. Or, if you work in the refining industry, you desktop computer could control all operations of the refinery by using a custom communication protocol to interchange data with all the individual process controllers in the refinery. And they could all be connected using TCP/IP as the base networking system.

Finally, it is the beauty of protocols to remove the drudgery of dealing with such mundane aspects of communication. When you use your phone, you just press some buttons; the 'protocol' built in 'below' your phone handles all those mundane details of connecting, maintaining, then tearing down the connection. Likewise, when you use your web browser, you simply supply a host name and the browser handles the rest for you. So when you write a program that opens a socket to somewhere, the library handles most of the details for you. You pert near only need to:

• open() or socket()
• connect() (maybe, if using a connection-oriented protocol)
• read() and write() data to your heart's content without worrying about packets, protocols, etc.
• close()

Again, a gross over-simplification, but it really doesn't take much more than that.

Look for an old Sun Microsystems "Network Programming" manual (from SunOS 4 days). It's relatively short, but it provided me a very clear introduction to using TCP/IP sockets. I still use the open/close/connect functions I wrote almost 20 years ago; I based them on the content of a few pages in that Sun manual.

[BestJewSinceJC]

Sockets do not implement protocols. Just as you connect to a socket, a socket connects to the protocol you requested. Otherwise, it would be akin to saying that the phone jack on your wall implements the phone system.

Agreed; the protocol is already implemented but the socket makes use of that protocol. If that was a response to my post, I never said that sockets implement TCP, I said that the services necessary for TCP have already been implemented and are made available for us by sockets. @ OP, if you're still around, check this out.

http://beej.us/guide/bgnet/

[jackthechemist]

Well thank you all very much. I have used socket methods before, with python, but didn't understand where or how the TCP came into play. It's all starting to make a bit more sense.

One last thing though:

If you are a certified auto-sado-masochist, you can write your own version of TCP. The rest of us pretty much use existing libraries.

Does anyone know how to go about this? Reason being, I never truly understood HTTP until I wrote some requests myself and manually elicited responses.

So after reading the TCP RFC which describes TCP packets being composed of headers which are composed of 16 bit post numbers, 32 bit sequence numbers etc...

http://www.faqs.org/rfcs/rfc793.html

I was wondering if anyone knew how I might manually write and send a TCP packet AND have another computer receive it. Or at least if you could point me in the right direction, cause I'm really lost on this one.

Haven't found that Solaris Manual yet, but managed to find some other useful material while looking :P

[Fest3er]

Well thank you all very much. I have used socket methods before, with python, but didn't understand where or how the TCP came into play. It's all starting to make a bit more sense.

One last thing though:

Does anyone know how to go about this? Reason being, I never truly understood HTTP until I wrote some requests myself and manually elicited responses.

So after reading the TCP RFC which describes TCP packets being composed of headers which are composed of 16 bit post numbers, 32 bit sequence numbers etc...

http://www.faqs.org/rfcs/rfc793.html

I was wondering if anyone knew how I might manually write and send a TCP packet AND have another computer receive it. Or at least if you could point me in the right direction, cause I'm really lost on this one.

Haven't found that Solaris Manual yet, but managed to find some other useful material while looking :P

Not Solaris. SunOS: it predates Solaris by a few years. :)

You can open the NIC in promiscuous mode; you then have 'bare-metal' access to ethernet and can compose any kind of packets you want to. It might be easier to set up a PPP link across an EIA-232 serial link if you *really* want to play with packets at such a low level.

The best way to understand communication protocols is to investigate several of them: LAPB/X.25, LAPD/ISDN, SS7, ATM, to get a feel for what makes a protocol and how they are put together.

Were it me, I would start with understanding LAPB (layer 2) and how it works. Then I'd move up to X.25 (layer 3) and understand it. They are easier protocols to grok and will give you a feel for layer 2 (point-to-point) protocols and for layer 3 (routed/addressed protocols). No, they aren't TCP/IP, but they are, in many ways, similar, just as X.25 and TCP/IP bear some structural and operational similarities with SS7 (the telecom protocol that would also be worth looking at for its layer2, layer3, layer 4 and higher layer protocol handling.

Then I'd look at the similarities and differences between LAPB (X.25's layer2) and LAPD (ISDN's layer 2). You could even look into LAPDm, GSM's layer2 air interface protocol.

Once you've started to understand those lower protocols, then you can move to ethernet, where you'll find the protocol layers to be kind-of similar, while quite different.

Use tcpdump() or some similar tool to capture and display packets for connection-oriented connectionless streams on a network. Limit the capture to a single stream between two specific computers. Then dissect the captured packets.

Good luck!

[jackthechemist]

Okay, well after reading and re-reading posts on various forums, and then reading and re-reading just about everything else lol I've not only managed to mentally separate the formerly intertwined concepts of sockets and TCP from each other, but also (mostly thanks to a couple informative replies to my questions, for which I'm grateful) a much clearer understanding of protocols in general. ^_^

AND I think I found what I was looking for: raw sockets!

There are likely other methods, and apparently a wealth of protocols, but for now I will focus on using sockets, and then raw sockets. Further, I think I will take your advice F3ster and study some other protocols; I never really learn so much about windows as I did when I was trying to understand Linux.

That said, I suppose I should mark this thread as resolved? Yes.