This question already has an answer here:
What is the use/purpose of MQTT QoS?
(1 answer)
Closed 4 years ago.
MQTT is a protocol based on TCP, and, TCP is a reliable transfer protocol.
Since TCP is reliable, then why there's a level 0 QoS in MQTT which represent message from publisher to receiver may lost ?
Or more, since TCP naturally supports reliable transport, then why MQTT need a concept of QoS ?
Say you've written an MQTT message to a TCP link but the TCP link errors out before you receive an acknowledgement for the other end. The other end may or may not have received the MQTT message. An MQTT implementation has to make a decision of whether or not to try to send the message over another link or after the TCP link is re-established. To do this, it needs to know whether the message is essential no matter how much it's delayed or whether there's no point in resending it because it's obsolete if not received promptly.
Related
For a service which just returns a small number when queried such as 30, or 10, but would have to handle up to 5 or so requests at any instance, would TCP or UDP be a better protocol? I am leaning towards UDP, but I wanted some expert opinions. I am looking for relatively quick reply times as well. Could you tell me what the advantages of each would be for a service like this? Thanks.
TCP is a reliable connection-based protocol. So, you are guaranteed that data is sent/received - the packets are automatically re-sent if they are not verified to be received on the other end. However, there is the overhead of the three-way handshake for establishing the connection.
TCP is used for protocols like HTTP where there is a one-time exchange of information (the HTTP Request and Reply).
UDP is an unreliable connection-less protocol. So you can simply send / receive a packet but you have no (automatic, OS stack-provided) way of verifying that the other end got your message. If you care, you have to implement some kind of ACK yourself.
UDP is used often for more continuous, "streaming" type protocols. For example, many online multiplayer games use UDP to exchange game information to/from the host. They do this on a continual, periodic basis. So if a packet is lost, it's not really a big deal, because another update is just around the corner. It would be far worse for the gameplay if you had to wait for that (now stale) update to be re-transmitted.
DNS is also implemented over UDP.
Ultimately the choice is yours. I would probably default to TCP for most cases, and only use UDP in a scenario like I described.
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.
I am trying to simulate a wifi video transmission and for that I created a connection using a socket between 2 devices, however I then started to doubt whether this is required or if I was supposed to create a UDP connection.
I think I'm just confused on terms here and I've Googled and I found out that Wifi can has TCP or UDP my question would then be would a Wifi Transmission over TCP be as reliable for a simulation as one with UDP?
I'd suggest you to read Difference between TCP and UDP?.
For streaming like video transmission you would generally want to use UDP. If a packet cannot reach the server in time, it'd better be discarded than pausing the whole transmission in order to wait for one tiny missing packet that just contains the other person blinking.
But obviously it's up to you and how you implement your software.
You may need to read up a bit on the TCP/IP protocol. TCP and UDP are just types of packets/datagrams. The main difference is that TCP packets include extra protocol information, whereas UDP are simpler packets with just a destination, the data itself, and a checksum.
The upshot is that the sender of a UDP packet has no way of knowing whether or not the packet was received at the other end. Often this doesn't matter - because it may be handled in other ways by higher layers in the software, or can be simply lost and ignored without any negative consequences. So UDP can be a more efficient use of the bandwidth, in some scenarios - because there is less protocol information being exchanged, and therefore more actual data. Plus TCP is more complicated because you have to handle the protocol stuff.
So when you create your system, you have a choice - either TCP or UDP packets, depending on what you are trying to achieve and how you want to go about it. But both packet types are really all part of the "tcp/ip" protocol stack, and have similarities.
This question already has answers here:
Difference between TCP and UDP?
(13 answers)
Closed 4 years ago.
What exactly is a TCP connection?
I understand there isn't a physical connection from the client to server. Is this connection just the client's socket being linked with the new socket created by the server after the three-way-handshake?
Thereafter once the "connection" is set up, the sockets on either ends of the connection then know where to send their packets.
How does this differ from the way UDP functions other than the initial handshake with TCP?
Is it that each server socket only has one client that sends packets to that particular socket?
What are some possible advantages of having a dedicated connection between hosts? My understanding of TCP and UDP is still very basic, so broad generalizations should suffice.
Let's break this up into parts. First of, the network is based in IP, which is a protocol that assigns an address to each network node, and which allows you to send small amounts of data (usually up to 64kB, but typically only 1500B) from one node to another.
That by itself isn't worth much yet, because we can't make any checks that the data actually arrived, and that it arrived in the right order. If we want an abstract mechanism to transmit arbitrary amounts of data and ensure that they arrived, we need another protocol on top of the network that handles this "transmission". And that's the purpose of TCP.
However, in parallel to TCP, there's another "transmission" protocol that doesn't do any checking at all and has no reliability, UDP. UDP is just a thin wrapper around raw IP packets, which adds a little bit of meta data (like a port number).
UDP is still useful, though, since there are many situations in which the data integrity is already handed off to an even higher protocol, so there's no need for a complex transmission protocol. This is for example used in virtual networking services, where another instance of TCP/IP is typically run over a UDP channel. (Making the channel use a reliable protocol like TCP can actually have disastrous consequences in that case due to resend cascades.)
So the term "TCP connection" refers to the application of the TCProtocol. The protocol is stateful, naturally, and typically proceeds in a SYN-ACK-data-FIN sequence, or SYN/RST in case of a rejected transmission; both peers maintain a status of the connection (handshake, established, closing, closed.) TCP also introduces the terms "server" and "client", the server being the peer that listen()s for an incoming connection.
The main difference between TCP and UDP sockets is that UDP is conectionless and doesn't use any confirmation that the other end received the data.
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications such as the World Wide Web, email, remote administration and file transfer rely on. Other applications, which do not require reliable data stream service, may use the User Datagram Protocol (UDP), which provides a datagram service that emphasizes reduced latency over reliability.1
** http://en.wikipedia.org/wiki/User_Datagram_Protocol: **
"Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers)."
'Compatible' is a very poor choice of words here. 'Supports' is what is really being described. TCP is a point to point protocol, by design. Period. TCP multicast is a contradiction in terms.
EDIT: I updated the Wikipedia page to reflect this comment.
EDIT 2: Incredibly enough, somebody has removed all mention of multicast from the Wikipedia UDP page since this question was posted. I fixed it. Again.
TCP establishes a connection between the sender and the receiver. The sender sends a packet, then waits for acknowledgement from the receiver before sending another1. If a packet goes too long without being acknowledged, it resends the packet until it does receive an acknowledgement (that's how it gets its reliability).
In the case of multicast and broadcast, the sender doesn't even know how many receivers there might be, not to mention who they are. That makes it pretty much impossible for it to wait for confirmation and re-send packets if somebody doesn't acknowledge a packet correctly.
1Technically, there's a "window" that allows it to send, say, five packets before it receives acknowledgement, but you get the idea -- it still needs to know who's receiving, and get acknowledgement of packets that it sent, and re-send packets if they're not acknowledged.
TCP incorporates both flow control and reliability based on acknowledgment from the recipient of the data. A broadcast or multicast transmitter has no idea which or how many other nodes are listening; even if it did by some sort of multipoint synchronization algorithm similar to TCP's point-to-point synchronization, flow control would be an issue because the receiver under the worst conditions would limit the speed of the entire flow.
The short answer is because broadcast TCP is complicated.
The long answer is that the important parts of the TCP protocol, namely reliability and congestion control when ported to broadcast semantics are easily subject to abuse, don't scale well, and multicast is simply and optional component of the IPv4 standard and either not implemented or disabled at most core routers.
Many papers have been published investigating new protocols to improve scalability; IPv6 promotes multicast to a core protocol requirement and alongside source-specific-multicast significantly improves core routing support and security; leaving the still significant area of abuse.
Abuse covers many aspects of the protocol, from man-in-the-middle attacks, to overloading network infrastructure, causing network storms of traffic upstream to the source.
With a Windows machine today you can use the PGM protocol with streams support which operates pretty much as broadcast TCP. It is used by Microsoft's messaging system MSMQ.
http://msdn.microsoft.com/en-us/library/ms740125(v=vs.85).aspx