Mixing
Why is a TCP Socket identified by a 4 tuple?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Newbie to networking here. I'm reading the Computer Networking (3rd edition) book, and in section 3.2 they are discussing multiplexing / demultiplexing for both UDP and TCP.
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?
The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80 of the server even though the server has established a TCP socket specifically for that session on a different port. In that case, TCP has to use the source IP and source port information to demultiplex to the correct socket. It can't rely solely on the source IP information, because a single host can establish multiple sessions, but each session has to be on a different port.
The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.
Is this correct or have I reached the wrong conclusion?
tcp protocol-theory udp
edited 3 hours ago
jonathanjo
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
Newbie to networking here. I'm reading the Computer Networking (3rd edition) book, and in section 3.2 they are discussing multiplexing / demultiplexing for both UDP and TCP.
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?
The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80 of the server even though the server has established a TCP socket specifically for that session on a different port. In that case, TCP has to use the source IP and source port information to demultiplex to the correct socket. It can't rely solely on the source IP information, because a single host can establish multiple sessions, but each session has to be on a different port.
The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.
Is this correct or have I reached the wrong conclusion?
tcp protocol-theory udp
edited 3 hours ago
jonathanjo
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Newbie to networking here. I'm reading the Computer Networking (3rd edition) book, and in section 3.2 they are discussing multiplexing / demultiplexing for both UDP and TCP.
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?
The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80 of the server even though the server has established a TCP socket specifically for that session on a different port. In that case, TCP has to use the source IP and source port information to demultiplex to the correct socket. It can't rely solely on the source IP information, because a single host can establish multiple sessions, but each session has to be on a different port.
The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.
Is this correct or have I reached the wrong conclusion?
tcp protocol-theory udp
edited 3 hours ago
jonathanjo
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Newbie to networking here. I'm reading the Computer Networking (3rd edition) book, and in section 3.2 they are discussing multiplexing / demultiplexing for both UDP and TCP.
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?
The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80 of the server even though the server has established a TCP socket specifically for that session on a different port. In that case, TCP has to use the source IP and source port information to demultiplex to the correct socket. It can't rely solely on the source IP information, because a single host can establish multiple sessions, but each session has to be on a different port.
The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.
Is this correct or have I reached the wrong conclusion?
tcp protocol-theory udp
tcp protocol-theory udp
edited 3 hours ago
jonathanjo
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 3 hours ago
jonathanjo
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 3 hours ago
jonathanjo
7,120623
edited 3 hours ago
jonathanjo
7,120623
edited 3 hours ago
jonathanjo
7,120623
7,120623
asked 3 hours ago
Steven L.
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
Steven L.
1111
asked 3 hours ago
Steven L.
1111
1111
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Steven L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago
add a comment |Â
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information
NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)
I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.
A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.
UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.
You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.
even though the server has established a TCP socket specifically for that session on a different port
I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.
If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.
(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connected connection. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of thinking about UDP datagram exchange between two processes. Remember Berkeley library is not just IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)
answered 3 hours ago
jonathanjo
7,120623
add a comment |Â
up vote
0
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
Please don't mix network programming (sockets) with network protocols.
However in the case of UDP you also have this 4-tuple!
The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.
For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).
On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).
This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.
answered 14 mins ago
Martin Rosenau
6356
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information
NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)
I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.
A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.
UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.
You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.
even though the server has established a TCP socket specifically for that session on a different port
I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.
If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.
(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connected connection. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of thinking about UDP datagram exchange between two processes. Remember Berkeley library is not just IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)
answered 3 hours ago
jonathanjo
7,120623
add a comment |Â
up vote
3
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information
NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)
I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.
A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.
UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.
You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.
even though the server has established a TCP socket specifically for that session on a different port
I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.
If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.
(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connected connection. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of thinking about UDP datagram exchange between two processes. Remember Berkeley library is not just IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)
answered 3 hours ago
jonathanjo
7,120623
add a comment |Â
up vote
3
down vote
up vote
3
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information
NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)
I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.
A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.
UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.
You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.
even though the server has established a TCP socket specifically for that session on a different port
I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.
If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.
(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connected connection. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of thinking about UDP datagram exchange between two processes. Remember Berkeley library is not just IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)
answered 3 hours ago
jonathanjo
7,120623
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information
NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)
I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.
A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.
UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.
You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.
even though the server has established a TCP socket specifically for that session on a different port
I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.
If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.
(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connected connection. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of thinking about UDP datagram exchange between two processes. Remember Berkeley library is not just IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)
answered 3 hours ago
jonathanjo
7,120623
edited 2 hours ago
answered 3 hours ago
jonathanjo
7,120623
answered 3 hours ago
jonathanjo
7,120623
answered 3 hours ago
jonathanjo
7,120623
7,120623
add a comment |Â
add a comment |Â
up vote
0
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
Please don't mix network programming (sockets) with network protocols.
However in the case of UDP you also have this 4-tuple!
The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.
For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).
On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).
This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.
answered 14 mins ago
Martin Rosenau
6356
add a comment |Â
up vote
0
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
Please don't mix network programming (sockets) with network protocols.
However in the case of UDP you also have this 4-tuple!
The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.
For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).
On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).
This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.
answered 14 mins ago
Martin Rosenau
6356
add a comment |Â
up vote
0
down vote
up vote
0
down vote
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
Please don't mix network programming (sockets) with network protocols.
However in the case of UDP you also have this 4-tuple!
The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.
For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).
On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).
This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.
answered 14 mins ago
Martin Rosenau
6356
In the UDP protocol, a socket is uniquely identified by the source IP and the source port.
Please don't mix network programming (sockets) with network protocols.
However in the case of UDP you also have this 4-tuple!
The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.
For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).
On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).
This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.
answered 14 mins ago
Martin Rosenau
6356
answered 14 mins ago
Martin Rosenau
6356
answered 14 mins ago
Martin Rosenau
6356
answered 14 mins ago
Martin Rosenau
6356
6356
add a comment |Â
add a comment |Â
Steven L. is a new contributor. Be nice, and check out our Code of Conduct.
Steven L. is a new contributor. Be nice, and check out our Code of Conduct.
Steven L. is a new contributor. Be nice, and check out our Code of Conduct.
Steven L. is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f54344%2fwhy-is-a-tcp-socket-identified-by-a-4-tuple%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Hello Steven and welcome. There are a number of different books called "Computer Networking" in their 3rd edition .. which one are you reading?
– jonathanjo
2 hours ago
See this answer for what the RFC for TCP explains about sockets and connections.
– Ron Maupin♦
13 mins ago