I would like to define a specification for TCP/IP communication protocol.
If there is a specification sample used in basic TCP/IP communication such as the REST API specification document, I would appreciate it if you could share it.
thanks
Related
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 am currently learning about networking. I am going through the TCP IP and OSI model and try to pick apart what protocol belongs to which layer. I am a bit confused over Media Access Control. Does it just refer to the hardware id of the network card or is it the name of the protocol responsible for it? I tried to find any RFCs for MAC on IETF to provide some definitions for me, but I couldn't find anything.
"MAC" stands for media access control - it's a sublayer of the data link layer (L2) in the OSI model.
One of the most popular protocols in this layer is Ethernet which covers the physical layer and the data link layer. You can find all about Ethernet at IEEE 802.3 (requires registration but is free).
Another extremely popular L1/L2 protocol stack is WiFi (IEEE 802.11) but that's a lot more complicated and hard to start with.
No, the MAC is not a protocol in that you won't find any 'MAC spec' that you can implement. MACs are typically embedded in hardware devices and expose functionality to send and receive frames to the media that they're controlling.
How they expose that functionality is up to the manufacturer of the MAC. They don't follow any standard protocol. You might find simple SPI interfaces, register-based access, DMA transfer or others.
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.
Transport layer and datalink layer of OSI model provide similar functionality. If one of said was already there, why was the other needed
They do provide some similar functionality, but at a different level. The link layer provides for communications for MAC addresses on the same LAN; the transport layer provides for communication between any devices anywhere.
A good design typically includes the concept of separation of concerns. That is, the data link layer need only be concerned with how to get packets to other hosts on that specific link. Remember that Ethernet is not the only link type in the world. You might need to get packets to the other side of a PPP link over an analog modem. Since the network layer is separate, you can use a different data link type and your network layer packets can remain the same.
You may refer to an image here for reference.
Physical: Only knows about bits. Handled byires and hubs
Data Link: Knows about MAC addresses. Handled by layer 2 switches
Network: Knows about IP addresses. Handled by routers or layer 3 switches
Transport: TCP comes here
Could i inject packets to Linux TCP stack without modifying the ethernet driver? Could i do this with using a library or sth ?
Thank you,
If by 'inject packets to Linux TCP stack' you mean send some data that the Linux kernel will treat as a frame coming from an Ethernet interface then you can use a 'tap' device. If an IP packet (layer 3) is good enough, then use a 'tun' device.
http://en.wikipedia.org/wiki/TUN/TAP
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
Libnet
Libnet is a generic networking API that provides access to several protocols. It is not designed as a 'all in one' solution to networking. Currently many features that are common in some network protocols are not available with Libnet, such as streaming via TCP/IP. We feel that Libnet should not provide specific features that are possible in other protocols. If we restrict Libnet to the minimal needed to communicate (datagram/packets) then this allows it to support more interfaces.
Otherwise, if you're just wondering about injecting hand-crafted packets into the network, read the man pages and look for online help with raw sockets. Some good places to start are man 7 raw, man packet, and there are some ok tutorials at security-freak.net, though the code there is not written particularly well for my tastes.