I think multiple sockets can be associated with same TCP port.
But can the same thing work for UDP?
The only way to associate multiple sockets with a port in TCP is by listening and then accepting.
The purpose in that case is to give every incoming client a unique socket so as to keep their byte streams separate.
You don't need that in the case of UDP because there are no byte streams. You can write an entire UDP server using a single UDP socket. You just read, despatch to a handler for that client, the handler writes the response back via the same socket.
Yes, it is also possible to have multiple sockets using a single UDP port.
Related
I've seen while searching that it is possible to use two different programs on the same computer communicating over the network using the same port and same network interface provided one use UDP and the other TCP. However I didn't get a good explanation, how does it actually work and why this is possible?
Is it also possible for multiple programs to use the same UDP port since UDP does not establish a real connection between the peers, but just sends the packets to an address? I understand it's not possible with TCP as it creates a synchronized connection between the server and the client, but what about UDP?
Please explain in details if possible, or link a good article on the topic.
The other answers are correct but somewhat incomplete.
An IP (aka "INET") socket "connection" (i.e. communication between two processes, possibly on different machines) is defined by a 5-tuple: protocol, source address, source port, destination address, destination port. You can see that this is not limited to a stateful connection such as TCP.
This means that you can bind different processes to any unique instance of that 5-tuple. Because the "protocol" (e.g. TCP and UDP) is part of the differentiating factor, each can have a different process.
Theoretically, you could bind different services to the same TCP port if they bind to different interfaces (network cards, loopback, etc.) though I've never tried it.
It is standard practice, however, to always use the same service on the same port number. If both UDP and TCP are supported, they're just different ways of communicating with that same service. DNS, for example, uses UDP on port 53 for lookup because they are small requests and it's faster than creating a TCP connection but DNS also uses TCP on port 53 for "transfers" which are infrequent and can have large amounts of data.
Lastly, in complete accuracy, it isn't necessarily a 5-tuple. IP uses the "protocol" to pass to the next layer such as TCP and UDP though there are others. TCP and UDP each seperately differentiate connections based on the remaining 4 items. It's possible to create other protocols on top of IP that use completely different (perhaps port-less) differentiation mechanisms.
And then there are different socket "domains", such as the "unix" socket domain, which is completely distinct from "inet" and uses the filesystem for addressing.
The destination isn't identified by IP Addr:Port alone. There is another thing - IP header has a field called Protocol which differentiates the TCP and UDP endpoint. As such it becomes possible for two process to bind to same IP:Port as long as communication protocol is different.
The endpoint of a connection is for UDP and TCP defined by IP, protocol (TCP or UDP) and port. This means as long as you use a different protocol the endpoint of the communication is different too.
Because they are not the only component of the means of address. It's the same as why you can have two houses with the same number on different streets, or why you know John Whorfin is not the same Red Lectroid as John Bigbooté.
Each IP packet contains a field that says which transport-layer protocol is to be used, and within the domain of that protocol is a set of ports that can be the same as in any other protocol because they are actually a completely separate set.
As for the second question, there are answers elsewhere.
I can send a tcp syn, and I receive a syn/ack back, but at that point linux sends a tcp rst because it was not linux tcp that opened the connection.
I'm wondering if I can stop the rst, or if there's another way to manually perform the handshake so I can send arbitrary packets after it.
I'm implementing a nat for a class and I'm trying to debug more effectively.
The discussion surrounding this question is probably helpful.
If you are doing this for experimental reasons (i.e. not trying to interact with real tcp services) I would recommend that you set the protocol number to 253-254 instead of the regular 6 for tcp, that should allow you to prevent the kernel from picking up on the packets that you are generating.
Is there any method to broadcast a signal or message in TCP? I know that for broadcasting UDP is used.
For example multiple clients connected with server and server sends a broadcast signal to all of connected clients at the same time. Is it possible using TCP?
No, TCP is connection oriented and designed for single end to end communications.
I'm trying to send large files using UDP Adobe air to CPP. While transferring large files some packets are missing. How can I retrieve the missing packets data? I'm first of all connecting client(air) with server(cpp) using tcp. After connection establishment I'm starting file transfer. I am planning to get the file missing data using tcp and then resending the missing packets using tcp. Can anybody tell me how can i come to know which packets are missing while transferring. Thank you.
Can you please clarify what is happening? You say you are sending files over UDP yet connecting to the sever with TCP - the two protocols are mutually exclusive over a single connection.
UDP does not provide any mechanism for detecting packet loss (that's what TCP is for) so by default you won't be able to work out whether packets have been lost.
You should use TCP for sending files as it manages sending/resending packets for you.
As stated in the Air ServerSocket documentation (http://help.adobe.com/en_US/air/reference/html/flash/net/ServerSocket.html):
All packets [sent over TCP] are guaranteed to arrive (within reason) — any lost packets are retransmitted. In general, the TCP protocol manages the available network bandwidth better than the UDP protocol. Most AIR applications that require socket communications should use the ServerSocket and Socket classes [TCP] rather than the DatagramSocket class [UDP].
See this page for more information on the Air networking classes:
http://help.adobe.com/en_US/air/html/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfb
my guess, tcp is slower because it does a resend when a packet gets lost. so that's probably why it's slower. but on the other hand, checking which packets get lost and re-send them by udp will also take longer ...
i would go for TCP instead of UDP
Like Sly says, udp seems the wrong tool to use here
is it possible to send multiple tcp or udp packets on a single ip packet? are there any specifications in the protocol that do not allow this.
if it is allowed by the protocol but is generally not done by tcp/udp implementations could you point me to the relevant portion in the linux source code that proves this.
are there any implementations of tcp/udp on some os that do send multiple packets on a single ip packet. (if it is allowed).
It is not possible.
The TCP seqment header does not describe its length. The length of the TCP payload is derived from the length of the IP packet(s) minus the length of the IP and TCP headers. So only one TCP segment per IP packet.
Conversely, however, a single TCP segment can be fragmented over several IP packets by IP fragmentation.
Tcp doesn't send packets: it is a continuous stream. You send messages.
Udp, being packet based, will only send one packet at a time.
The protocol itself does not allow it. It won't break, it just won't happen.
The suggestion to use tunneling is valid, but so is the warning.
You might want to try tunneling tcp over tcp, although it's generally considered a bad idea. Depending on your needs, your mileage may vary.
You may want to take a look at the Stream Control Transmission Protocol which allows multiple data streams across a single TCP connection.
EDIT - I wasn't aware that TCP doesn't have it's own header field so there would be no way of doing this without writing a custom TCP equivalent that contains this info. SCTP may still be of use though so I'll leave that link.
TCP is a public specification, why not just read it?
RFC4164 is the roadmap document, RFC793 is TCP itself, and RFC1122 contains some errata and shows how it fits together with the rest of the (IPv4) universe.
But in short, because the TCP header (RFC793 section 3.1) does not have a length field, TCP data extends from the end of the header padding to the end of the IP packet. There is nowhere to put another data segment in the packet.
You cannot pack several TCP packets into one IP packet - that is a restriction of specification as mentioned above. TCP is the closest API which is application-oriented. Or you want to program sending of raw IP messages? Just tell us, what problem do you want to solve. Think about how you organize the delivery of the messages from one application to another, or mention that you want to hook into TCP/IP stack. What I can suggest you:
Consider packing whatever you like into UDP packet. I am not sure, how easy is to initiate routing of "unpacked" TCP packages on remote side.
Consider using PPTP or similar tunnelling protocol.