As I understand it, a TCP message is put out on the network with an address and a port number. If I’m at that IP address (me being a process, “at” meaning I’m running on the machine with that address) and I’m “listening” on that port, then I pick up the message. That’s rather one-way, since (as described) I don’t reply to that message, just read it.
So what is “opening a socket”? I know a socket open call can fail, so I presume that means that some reply didn’t come back–how does that reply get to the calling process if the open succeeds?
But note there is a considerable amount of “handshaking” between sender and receiver; it includes the possibility of “I didn’t receive a valid copy of packet #17 - could you please re-send.”
“Open a socket” doesn’t mean anything as Chloe uses it on 24. It’s a nonsense television phrase.
What she usually means is, “temporarily open a port on the firewall so a particular TCP connection can be made from the outside,” but that doesn’t sound as good.
You want small words? No problem, the “words” used by the TCP handshake process are small.
The client that wants to “talk” to a server sends a little message called a SYN. (synch) The server responds with a message called SYN-ACK (acknowledge) and then the client sends back an ACK, and the channel is open.
Essentially, the client picked up the phone and dialed a number, the server answered with “Hello, you want to talk?” and the client says “Yes. Let’s start!”
From that point, the functionality of TCP provides for an ongoing “Did you get that last bunch of data? It was bundle #932.” and the other party will respond with “I got #932” or “Nope. Send it again.”
In TCP, you are polite and you do acknowledge everything you receive.
TCP is built on a structure of responses and responses to those responses. One “denial of service” attack intended to shut down a service is to send lots of SYN messages to the server and ignore the SYN-ACK responses. This is called a SYN flood. Send out enough of these, and the server wastes all of its time waiting for responses.
When it’s all done, you end the connection by sending a FIN message and the other party responds with FIN-ACK. You send a final ACK and you’re done.
A socket is just a standardized interface for breaking up your internet connection into 16536 “ports” and addressed by a certain 4-byte IP address. How computers find each other, what sort of protocol is used to send data from one to the other, etc. is all higher level stuff. “Sockets” themselves are just an idea, a generally agreed upon way to split up data that comes in through the ethernet cable, that doesn’t really have much to do with anything beyond that people thought it sounded cool.
“Opening” one, just means that you’re either setting up a program that tells the OS that it wants data sent to port X, or that you’re setting up a program to send data out for port Y of IP adress a.b.c.d (someone else.)
Again, how the computer establishes this “setting up” is somewhat independent of sockets. In general, your OS will translate what you’re asking to do with the socket into ARP translations, and IP lookups. But it does that invisibly, so it could be just doing ethernet (which doesn’t need to involve IP at all) or going out onto the internet and doing DNS lookups. That’s not part of sockets.
As a boy, I was warned about that in Sunday School. We were told to resist a flood of SYN. My repeated questions about how to resist, and just what kind of SYN I would encounter made my teacher very nervous. She cried, “ACK!”, turned on her heel, and left the room. :smack: We never saw her again. Years later, I heard, in whispers, that she was traded to the Methodists for a case of unleaven bread, and a prayer to be named later. The wages of SYN?
No. This is 100% wrong. A socket is a virtual connection between two machines. TCP is responsible for setting up and maintaining that connection. IP and the lower layers don’t even have any concept of a connection – they’re solely concerned with individual packets.
This makes no sense. You say a socket is lower level than TCP and IP, then you define it by describing a TCP port and an IP address? Also, the range of valid ports is in fact 1-65535.
What an amazing load of crap. No, that’s nothing to do with sockets at all. You’ve described what is called the MAC layer.
I would love to see you make a DNS call over the internet without opening up a socket. DNS is layer 5, it sits above TCP and IP (which are what define a socket).
The OSI model is the logical basis of modern networking. Data is handled differently at every layer.
TCP and IP are seperate protocol suites - TCP covers the transport layer and IP covers the network layer. What you’re describing is the network layer - information at the network layer doesn’t “know” of any persistant connections between two systems, or when the last packets were acknowledged, etc. It concerns knowing where it is on the network and what route to take to get to its destination.
TCP on the other hand works on the transport layer. The transport layer is concerned with traffic control and the persistant connections. The transport layer doesn’t “know” how to get where it’s going - that’s the network layer’s job - but it keeps track of such things as whether or not previous packets arrived properly at their destination, how much it can send at one time before waiting for acknowledgement, etc.
Sockets are a logical idea to allow programmers to conceptually implement connections. It allows you to think of network traffic as a logical input/output device. Just like you might take in data from a keyboard and output it to a monitor, you could take data from and give data to a socket. Sockets are considered to be implemented at the session layer.
“Usually sockets are implemented over TCP but this is not required. They can be implemented over any transport protocol, such as SNA [1]. The concept of a socket is an entity that implements an API, regardless of the implementation.” Per Wikipedia, which is what I said.
That’s why we call them “TCP sockets”. Sockets are at layer 4, but there are other layer 4 protocols. Sockets have nothing to do with Layer 3(IP) and lower, other than the fact that they’re built on top of them.
I dunno. All the socket programming I’ve ever done, I’ve had to pass in IP addresses of some sort. So whether they’re intended to be so abstract as to not need any of that sort of thing, in implementation I’m not sure that’s been accomplished (nor how one would hope to accomplish a connection without an address.) And, I’ve also had to specify TCP, UDP, or whatever.
Blah, I hate trying to answer things when I’m half asleep.
As the Wikipedia says, “The combination of an IP address and a port number is referred to as a socket.” Anything else isn’t necessary for it to still be called a socket. And “opening a socket” is either setting yourself up as a host or a client, but the protocols for lookup, hand-shaking, and data transmission are all fairly well unconnected and could be anything, even several layers of different somethings.
Again, wrong. It is not higher than TCP/IP. It is not lower than TCP/IP. It is at layers 3 and 4 of the OSI stack, which in the case of the internet protocol is equal to TCP and IP.
You’re confusing socket programming with internet sockets. If you abstractly define socket as anything with 2 endpoints then it doesn’t really matter what you say, it’s correct. If on the other hand you’re talking about the most overwhelmingly common use case indicated by the term “sockets”, then there are very specific meanings involved and you are missing the mark on all of them.
OK, so when I “open a socket” how does the receiver ACK what I have sent? Do I have to be listening on a port? Since I’m sending to a remote port (e.g. 22.33.44.55:6666) I’m not guaranteed to be listening on some specific port, am I? How do firewalls affect this? If my firewall is open on port 6666 in both directions, does that guarantee that I’ll get an ACK when I send on 6666?
I’ll use the example of a web server. A web server, say with IP address 10.2.101.20, will be listening on TCP port 80. If I, with IP address 96.58.45.128 want to connect to this web server, I pick any source port I like(the TCP implementation will choose the source port), and then send a SYN packet to the webserver which will contain my IP and port(96.58.45.128:20000) and the destination IP and port(10.2.101.20:80). If the web server accepts the connection, it will response with a SYN/ACK packet*. The source of the SYN/ACK will be 10.2.101.20:80 and the destination will be 96.58.45.128:20000. I will then respond with an ACK packet, and then the connection is fully established.
Now, if I want to initiate a second connection with this same webserver before the first connection is closed, I just have to choose a different source port, like maybe 20001. Choosing a different source port gives me a connection that both sides can see is different from the original connection over port 20000.
Make sense?
Technically speaking, it could respond with separate ACK and SYN packets.
