I am studding the MQTT & TCP/IP protocol.
Since i'm able to know that, MQTT is based on the TCP so as the TCP/IP
& we refer MQTT though we have the TCP/IP Protocol.
Why don't we use TCP/IP instead of MQTT?
Is there any advantages of MQTT that makes it better solution than the TCP/IP protocol?
Which is more reliable & required less no of data packet to form a communication?
(Note : TCP/IP in the sense forming a network between 2 devices using normal TCP/IP protocol as in GSM modems "connect > transfer data > disconnect")
Is there any advantages of MQTT that makes it better solution than the TCP/IP protocol?
Yes, it offers things TCP doesn't offer, namely an application layer protocol. Other examples of such protocols are FTP, HTTP, SMTP.
You're asking the wrong question. IP makes sure you can send data to another machine, TCP makes sure this data is received in-order and acknowledged, and application-level protocols make sure you can make sense of the data you receive.
Without an application level protocol, you have no meaningful communication. Where each sockets programming example begins with "WriteLine" and "ReadLine" text message exchanges, that in itself is (albeit a very rudimentary) application level protocol, namely "client and server exchange text messages ending in a newline".
So, no, you cannot use TCP/IP without an application level protocol, because as soon as you start writing a program sending and/or receiving data, you have at that moment defined an application level protocol.
With its own problems. And that's why you shouldn't invent your own protocol, but use existing ones. Pick the one that suits your needs. Do you need to publish or subscribe messages to some broker, use MQTT.
Unless you know very well what you're doing, don't invent your own.
The benefits of using MQTT over TCP/IP far outweighs the data overhead it introduces. Also, MQTT was devised to solve a specific problem of getting sensor data from a remote system which could not be connected to the consumer of the sensor data all the time.
I looking for an example of SNMP running in a protocol different than UDP. I need to argue with a professor who said that it's only possible to run SNMP over UDP. Anyone knows how it works in ATM? In my mind SNMP is a layer 7 protocol and doesn't matter what protocol is used for transport, but I only found references to UDP. Please post the references.
SNMP of course can go over other protocols than UDP. For example, RFC 3430 defines SNMP over TCP,
https://www.rfc-editor.org/rfc/rfc3430
However, the widely used SNMP implementation is still UDP only in most cases, so rarely you see an application on TCP or other protocols (I knew some internal usage in Cisco).
Well, an argument is not really suggested, and hope you chat in a good manner with your professor.
From RFC 1157 'A Simple Network Management Protocol (SNMP)' #4:
Protocol Specification
The network management protocol is an application protocol by which
the variables of an agent's MIB may be inspected or altered.
Communication among protocol entities is accomplished by the exchange
of messages, each of which is entirely and independently represented
within a single UDP datagram using the basic encoding rules of ASN.1
(as discussed in Section 3.2.2). A message consists of a version
identifier, an SNMP community name, and a protocol data unit (PDU).
A protocol entity receives messages at UDP port 161 on the host with
which it is associated for all messages except for those which report
traps (i.e., all messages except those which contain the Trap-PDU).
Messages which report traps should be received on UDP port 162 for
further processing.
I want use Alljoyn to communicate between devices in smart factory.
However,it seems there is no such use cases not yet.
So,i want to know if Alljoyn can't be used in factory for some technical reasons,
for instance,stability or performance.
In my case, I need device can communicate directly.
So,publish-subscribe-based protocol,like MQTT,wouldn't work for me.
I don't get the specific problem of your case. But I'm going to answer anyway.
AllJoyn runs on the proximal network (local network) by using Wi-Fi, Ethernet or Power Line (PLC). And AllJoyn does not require a cloud to function, cloud network connection is optional. It works in your case as long as the local network functions properly.
Transport name Value Description
TRANSPORT_NONE 0x0000 No transport.
TRANSPORT_LOCAL 0x0001 The local transport.
TRANSPORT_TCP 0x0004 Transport using TCP as the underlying mechanism.
TRANSPORT_UDP 0x0100 Transport using UDP as the underlying mechanism.
TRANSPORT_EXPERIMENTAL 0x8000 Select a release-specific experimental transport.
TRANSPORT_IP 0x0104 Allow the system to decide between TCP or UDP.
TRANSPORT_ANY 0x0105 Allow the system to choose any appropriate transport.
AllJoyn supports both TCP/IP and UDP/IP transport mechanisms. While developing your app, you can decide to use which transport mechanism you want.
AllJoyn documentation states that;
If an AllJoyn application desires to only use TCP as the underlying
layer 4 mechanism, it can do so by specifying TRANSPORT_TCP in
advertisement, discovery and Session join and bind options.
As TCP guarantees all sent network packages will reach their destination in the correct order. In your case you can choose TCP communication as a more reliable option.
I have a question concerning tcp packet sniffing with golang.
We have written a small tool which captures all incoming TCP packets comming from a fibre Tap.
The current implementation uses a libpcap wrapper under Linux. We need to port this tool to Windows. Of course, it is not possible at the moment.
So my question is, is there a cross platform solution for sniffing packets? We only need TCP packets, IP headers , no Ethernet Data and not all features of libpcap.
If there is no cross platform solution, two Code implementation would be ok, too. I know one can use raw sockets under Linux (and with some limitations under Windows). Does Golang support raw sockets and is there an example implementation for sniffing packets with sockets?
Tanks!! :-)
You should be able to use the ipv4 package from go.net.
Package ipv4 implements IP-level socket options for the Internet Protocol version 4.
The ipv4.RawConn type and it's associated methods should work cross-platform.
A RawConn represents a packet network endpoint that uses the IPv4 transport. It is used to control several IP-level socket options including IPv4 header manipulation. It also provides datagram based network I/O methods specific to the IPv4 and higher layer protocols that handle IPv4 datagram directly such as OSPF, GRE.
There is also an equivalent package for ipv6.
Take a look at https://code.google.com/p/gopacket/ since it supports pcap (requires cgo for this) and can decode a number of protocols including tcp/ip.
This might be a silly question:
Does HTTP ever use the User Datagram Protocol?
For example:
If one is streaming MP3 or video using HTTP, does it internally use UDP for transport?
From RFC 2616:
HTTP communication usually takes place
over TCP/IP connections. The
default port is TCP 80, but other
ports can be used. This does not
preclude HTTP from being implemented
on top of any other protocol on the
Internet, or on other networks. HTTP
only presumes a reliable transport;
any protocol that provides such
guarantees can be used; the mapping
of the HTTP/1.1 request and response
structures onto the transport data
units of the protocol in question is
outside the scope of this
specification.
So although it doesn't explicitly say so, UDP is not used because it is not a "reliable transport".
EDIT - more recently, the QUIC protocol (which is more strictly a pseudo-transport or a session layer protocol) does use UDP for carrying HTTP/2.0 traffic and much of Google's traffic already uses this protocol. It's currently progressing towards standardisation as HTTP/3.
Typically, no.
Streaming is seldom used over HTTP itself, and HTTP is seldom run over UDP. See, however, RTP.
For something as your example (in the comment), you're not showing a protocol for the resource. If that protocol were to be HTTP, then I wouldn't call the access "streaming"; even if it in some sense of the word is since it's sending a (possibly large) resource serially over a network. Typically, the resource will be saved to local disk before being played back, so the network transfer is not what's usually meant by "streaming".
As commenters have pointed out, though, it's certainly possible to really stream over HTTP, and that's done by some.
Maybe just a bit of trivia, but UPnP will use HTTP formatted messages over UDP for device discovery.
Yes, HTTP, as an application protocol, can be transferred over UDP transport protocol.
Here are some of the services that use UDP and an underlying protocol for transferring HTTP data and streaming it to the end-user:
XMPP's Jingle Raw UDP Transport Method
A number for services that use UDT --- UDP-based Data Transfer Protocol, which is the a superset of UDP protocol.
The Transport Layer Security (TLS) protocol encapsulating HTTP as well as the above mentioned XMPP and other application protocols does have an implementation that uses UDP in its transport layer; this implementation is called Datagram Transport Layer Security (DTLS).
Push notifications in GNUTella are HTTP requests sent over UDP transport.
This article contains further details on streaming over UDP and its reliable superset, the RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?
Of course, it doesn't necessarily have to be transmitted over TCP. I implemented HTTP on top of UDP, for use in the Satellite TV Broadcasting industry.
If you are streaming an mp3 or video that may not necessarily be over HTTP, in fact I'd be suprised if it was. It would probably be another protocol over TCP but I see no reason why you cannot stream over UDP.
If you do you have to take into account that there is no certainty that your data will arrive at the other end, but I can take it that you know about UDP.
To answer you question, No, HTTP does NOT use UDP.
For what you talk about though, mp3/video streaming COULD happen over UDP and in my opinion should never happen over HTTP.
Maybe some change on this topic with QUIC
QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental transport layer network protocol developed by Google and implemented in 2013. QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to optimize connection-oriented web applications currently using TCP.
I think some of the answers are missing an important point. The choice between UDP and TCP should not be based on the type of data (e.g., audio or video) or whether the application starts to play it before the transfer is completed ("streaming"), but whether it is real time. Real time data is (by definition) delay-sensitive, so it is often best sent over RTP/UDP (Real Time Protocol over UDP).
Delay is not an issue with stored data from a file, even if it's audio and/or video, so it is probably best sent over TCP so any packet losses can be corrected. The sender can read ahead and keep the network pipe full and the receiver can also use lots of playout buffering so it won't be interrupted by the occasional TCP retransmission or momentary network slowdown. The limiting case is where the entire recording is transferred before playback begins. This eliminates any risk of a playback stall, but is often impractical.
The problem with TCP for real-time data isn't retransmissions so much as excessive buffering as TCP tries to use the pipe as efficiently as possible without regard to latency. UDP preserves application packet boundaries and has no internal storage, so it does not introduce any latency.
(This is an old question, but it deserves an updated answer.)
In all likelihood, HTTP/3 will be using the QUIC protocol, which is described as
multiplexed transport over UDP
So, from a certain point of view, you could say that HTTP/3 will be using UDP.
The answer: Yes
Reason: See the OSI model.
Explaination:
HTTP is an application layer protocol, which could be encapsulated with a protocol that uses UDP, providing arguably faster reliable communication than TCP. The server daemon and client would obviously need to support this new protocol. Quake 2 protocol proves that UDP can be used over TCP to provide a basis for a structured communication system insuring flow control (e.g. chunk ids).
http over udp is used by some torrent tracker implementations (and supporteb by all main clients)
In theory yes it is possible to use UDP for http but that might be problematic. Say for instance in your example a mp3 or a video is being streamed there will be problem of ordering and some bits might go missing as UDP is not connection oriented there is no retransmit mechanism.
HTTP/3 (aka QUIC) uses UDP instead of TCP.
https://http3-explained.haxx.se/en/the-protocol/feature-udp
UDP is the best protocol for streaming, because it doesn't make demands for missing packages like TCP. And if it doesn't make demands, the flow is far more faster and without any buffering.
Even the stream delay is lesser than TCP. That is because TCP (as a far more secure protocol) makes demands for missing packages, overwriting the existing ones.
So TCP is a protocol too advanced to be used for streaming.