Can I send datagrams over TCP?
What you want to look at is SCTP . It provides the ability to send datagrams over a reliable TCP-style connection:
Unlike TCP, SCTP can be characterized as write-oriented, which means the transfer of data in terms of messages, similar to the User Datagram Protocol (UDP), so that a group of bytes (messages) sent in one transfer (write) exactly read that group on receiver. TCP is thread-safe, transporting streams of bytes, which it reorders correctly in the event of an unexpected delivery. It however, has no posting boundaries, i.e. data structures in terms of their original transmitting device at the sender.
Take a look at SCTP one-on-one connection style, which is probably what you are looking for.
There are versions for most Unix / Linux operating systems and there is a third party implementation for Windows. See the end of the Wiki article I linked for more details.
source to share
SOCK_DGRAM because the type receives a UDP socket. You can of course encapsulate UDP in TCP, but you have to handle the user-space portion of UDP. Whether something is reliable depends on the protocol on the wire. If you are using TCP, it is reliable; UDP doesn't work.
To create a UDP socket:
int s; s = socket(AF_INET, SOCK_DGRAM, 0);
To create a TCP socket:
int s; s = socket(AF_INET, SOCK_STREAM, 0);
There are two common ways to send discrete chunks of data over a wire. You can use UDP and send a discrete chunk as a datagram, otherwise you can structure the TCP data and let it flow as a stream. Using TCP is generally easier and less error prone. If you are using UDP, just pass the time and keep asking for the same data until you get it.
source to share
In theory, nothing prevents you from using a TCP socket with SOCK_DGRAM. What you get is a reliable datagram transfer. Is it possible to use Berkeley sockets?
No, the Berkeley API provides an untrusted datagram or a reliable stream.
If you want to send reliable chunks over TCP, use a protocol that splits the stream into chunks. It's very easy to do.
source to share
Not really. TCP and UDP are protocols from the same layer, and they have features that only make sense to them. Take listen () and accept () for example.
You can send UDP header + data inside TCP packets, but that doesn't make sense. Why would you do this? Tunneling type? It's actually very easy to parse and assemble UDP packets by hand, but I don't see any real application in your scenario.
source to share
I haven't seen a single socket api that gave you this capability - and it will also defeat some of TCP's goals so that you can control data alignment. TCP is just a transport and its abstraction is a stream of bytes.
You will need to create your own message structure on top of TCP, which will give you the concept of messages that the application layer takes care of.
source to share
You can imitate things, but there is really no reason for this. Either you want reliable delivery or you want on-time delivery. TCP gives you the first, UDP gives you the second. The two cannot be mixed because TCP implements reliability by repeatedly reporting messages to the other side until they are acknowledged. Streaming usually requires reliable data delivery (so you can collect the stream), but for small messages where order is not important (such as datagrams), you don't need all this overhead (UDP pretty much ensures that messages on the at least won't be garbled, which is one of what TCP and UDP offer on a raw IP address).
Of course, there are other interesting cases in between these two extremes. For live streaming data (like video calls), you use RTP because you are streaming, but you can recover data faster after a delay.For messages that are too large for UDP (64kB is a strict upper bound since the header UDP only has 16 bits for its length field), you really need to use TCP for transport anyway so that you can reassemble the fragments (hence SOAP intercepts HTTP over TCP, not UDP).
source to share