I am trying to use Unix Socket to implement IPC and I know that Unix Socket is much more faster than TCP, but I still have 2 questions.
Is Unix Socket reliable as TCP?
Which layer is Unix Socket on in OSI?
Unix sockets are reliable like TCP, provided the sender and receiver keep participating.
A unix socket does not map to the OSI network socket layers. It is local only, between two processes on the same machine.
Related
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
i have a question about the trasport layer of the iso/osi network stack.
It's common to think that TCP is reliable but slow and UDP is fast but not reliable.
In several network applications, it is mandatory to implement an application-level ACK system also with TCP transport protocol in order to manage link interruptions and so on.
Assuming that the application scenario is this: local (small) network, typical small packet size (max 512 bytes), application-level ack system implementation. Why not use the protocol UDP as transport protocol in order to exploit its features such as speed, low latency and broadcast communication?
Thanks to all.
If you don't care about the Delivery (failure or successful delivery) of your message than UDP will be always a best choice.. But if you want to be sure whether the message is delivered or failed than think about other protocols rather than UDP.
In a small LAN it shouldnt be a big problem to use UDP, when the transferd Data isnt too "important" (which means if a packet is lost its no problem). More informations about the scenario are nessesary, if you use UDP you have to implement functions that check if you received all the information of the sender manually.
if you need the speed and if some lost packets are no problem (Voice Chat for instance) then use UDP.
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
I think multiple sockets can be associated with same TCP port.
But can the same thing work for UDP?
The only way to associate multiple sockets with a port in TCP is by listening and then accepting.
The purpose in that case is to give every incoming client a unique socket so as to keep their byte streams separate.
You don't need that in the case of UDP because there are no byte streams. You can write an entire UDP server using a single UDP socket. You just read, despatch to a handler for that client, the handler writes the response back via the same socket.
Yes, it is also possible to have multiple sockets using a single UDP port.
I'm trying to send large files using UDP Adobe air to CPP. While transferring large files some packets are missing. How can I retrieve the missing packets data? I'm first of all connecting client(air) with server(cpp) using tcp. After connection establishment I'm starting file transfer. I am planning to get the file missing data using tcp and then resending the missing packets using tcp. Can anybody tell me how can i come to know which packets are missing while transferring. Thank you.
Can you please clarify what is happening? You say you are sending files over UDP yet connecting to the sever with TCP - the two protocols are mutually exclusive over a single connection.
UDP does not provide any mechanism for detecting packet loss (that's what TCP is for) so by default you won't be able to work out whether packets have been lost.
You should use TCP for sending files as it manages sending/resending packets for you.
As stated in the Air ServerSocket documentation (http://help.adobe.com/en_US/air/reference/html/flash/net/ServerSocket.html):
All packets [sent over TCP] are guaranteed to arrive (within reason) — any lost packets are retransmitted. In general, the TCP protocol manages the available network bandwidth better than the UDP protocol. Most AIR applications that require socket communications should use the ServerSocket and Socket classes [TCP] rather than the DatagramSocket class [UDP].
See this page for more information on the Air networking classes:
http://help.adobe.com/en_US/air/html/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfb
my guess, tcp is slower because it does a resend when a packet gets lost. so that's probably why it's slower. but on the other hand, checking which packets get lost and re-send them by udp will also take longer ...
i would go for TCP instead of UDP
Like Sly says, udp seems the wrong tool to use here