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.
Related
In my understanding, the transport layer begins to use the port numbers which is the identifier for a process. However the transport layer still referred as host to host functionality. What is the reason in it?
(1) I don't think transport layer is commonly referred to as host to host, it is referred to as end-to-end, as in, it works on both endpoints, and not in the network itself. This was intended in original design. Of course now there are a lot of network devices that look into transport layer. However, main functionality is still on hosts.
(2) although transport layer begins to use ports to segregate applications/processes, transport layer is the one doing the segregation. One of its functionality is to take packets from the IP layer and attribute them to the correct application. In this sense, there is only one instance of transport layer per host. Several processes are using that single transport layer. (We could argue about whether tcp and udp processing are separate entities, but this is implementation detail. But all tcp packets, which can be processed on each core, have to be attributed to correct sockets, so there is one instance of tcp per host)
(3) ports do not identify processes, ports identify sockets. each process can open more than one socket. reverse is not true, a socket is attributed to a single process.
The main purpose of the Host-to-Host Layer or Transport Layer is to shield the upper layers from the process of sending data. Also provides an end-to-end connection between two devices during communication by performing sequencing, acknowledgments, checksums, and flow control. Applications using services at this layer can use two different protocols: TCP and UDP.
Protocols at the Host-to-Host Layer are:
TCP (Transmission Control Protocol)
TCP provides a connection-oriented, reliable services to the applications that use its services.
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.
If so, do you know examples of what can go wrong in a non-TCP network?
Learning about MQTT I came across several mentions of the fact that MQTT relies on TCP/IP stack. For example, from mqtt.org:
MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP
networks, whereas MQTT itself explicitly expects a TCP/IP stack.
But if you read the reference documents, you won't finding anything like that. Moreover, there's QoS field that can be used for reliable delivery and whose values other than 0 are essentially useless in TCP/IP networks. Right now I see nothing that would prevent me from establishing an MQTT connection using UNIX pipe, domain or UDP socket rather than TCP socket.
MQTT just needs a delivery that is ordered and reliable, it doesn't have to be TCP. SCTP works just fine, for example, but UDP doesn't because there is no way to guarantee your large PUBLISH packet made up of multiple UDP packets will arrive in order and complete.
With regards TCP reliability, in theory what you are saying is true, but in practice when an application calls write() and receives a successful return, it can't guarantee when the data has actually made it out of the computer to the remote host. All write() (or send()) does is copy the data to the kernel buffers, at which point you have no further control.
The only way to be sure that a message reaches the remote host at the application level is to have the remote host reply.
MQTT-SN (for sensor Network ) is the solution for the problem that MQTT was having while running over TCP/IP .
There is a concept of MQTT gateway which is brought in in for MQTT-SN which helps in bringing non-TCP / IP implementation.
http://emqttd-docs.readthedocs.io/en/latest/mqtt-sn.html
Is there any low level network library for Internet protocol suite?
A library for capturing and sending Ethernet frames (Link layer), handling IP and ICMP packets (Internet layer), Transport layer and so on.
http://en.wikipedia.org/wiki/Internet_protocol_suite
Using netfilter in linux, you can create rule for INPUT, OUTPUT, and FORWARD. You can also use -j QUEUE to send specific rule chain to the QUEUE. Then you may use libnetqueue_filter library to read the packets from queue and take necessary action. e.g. ACCEPT, or DROP them.
In windows, however, this task is not easy. WinPcap only send a copy of the packets to you. It means you cannot decide what to do with the incoming traffic (drop, accept, or queue them). You may want to use the winDivert, or WinPkFilter to do it.
For Windows check out WinPcap or for Linux the Netfilter project.
Can someone explain the concepts of IPoIB and TCP over infiniband? I understand the overall concept and data rates provided by native infiniband, but dont quite understand how TCP and IPoIB fit in. Why do u need them and what do they do? What is the difference when someone says their network uses IPoIB or TCP with infiniband? Which one is better? I am not from a strong networking background, so it would be nice if you could elaborate.
Thank you for your help.
InfiniBand adapters ("HCAs") provide a couple of advanced features that can be used via the native "verbs" programming interface:
Data transfers can be initiated directly from userspace to the hardware, bypassing the kernel and avoiding the overhead of a system call.
The adapter can handle all of the network protocol of breaking a large message (even many megabytes) into packets, generating/handling ACKs, retransmitting lost packets, etc. without using any CPU on either the sender or receiver.
IPoIB (IP-over-InfiniBand) is a protocol that defines how to send IP packets over IB; and for example Linux has an "ib_ipoib" driver that implements this protocol. This driver creates a network interface for each InfiniBand port on the system, which makes an HCA act like an ordinary NIC.
IPoIB does not make full use of the HCAs capabilities; network traffic goes through the normal IP stack, which means a system call is required for every message and the host CPU must handle breaking data up into packets, etc. However it does mean that applications that use normal IP sockets will work on top of the full speed of the IB link (although the CPU will probably not be able to run the IP stack fast enough to use a 32 Gb/sec QDR IB link).
Since IPoIB provides a normal IP NIC interface, one can run TCP (or UDP) sockets on top of it. TCP throughput well over 10 Gb/sec is possible using recent systems, but this will burn a fair amount of CPU. To your question, there is not really a difference between IPoIB and TCP with InfiniBand -- they both refer to using the standard IP stack on top of IB hardware.
The real difference is between using IPoIB with a normal sockets application versus using native InfiniBand with an application that has been coded directly to the native IB verbs interface. The native application will almost certainly get much higher throughput and lower latency, while spending less CPU on networking.