In our system, we used to test the connectivity between different nodes using ICMP messages. But out of security concern, this keep alive mechanism is required to be banned by our customers. So we have to replace the ICMP message with some other protocol messages. Currently, our solution is using TCP. Obviously, this solution has at least 2 disadvantages:
1. failures occurred on one TCP connection don't necessarily mean the same thing happened to the others, and don't mean lower-layer connectivity(eg, IP) failures as well.
2. establishing a TCP connection and sending/receiving TCP message are quite time-consuming, which is another challenge to our existing connectivity testing schedule.
I'm wondering if there is any other solutions other than TCP that can meet our requirement.
Related
I'm trying to understand how to correctly implement p2p communication for the torrent protocol. Specification is not clear on this account.
If I, as a client, connect to a peer, then send the handshake, establishing communication, then I can send messages to that peer and receive responses. That is quite understandable from the client standpoint. What I don't understand is if the peer wants to send certain requests to me, in this case the peer is in a client role and I'm a peer in regards to it, will it use the same opened connection which I initiated or will it try to establish a new connection?
That leads to another question. Is it possible or is it normal to establish multiple connections to the same peer?
in this case the peer is in a client role
As far as the wire protocol goes there is no special 'client role' distinct from a server role. Both peers are equal and perform and support the same set of operations - give or take some protocol extensions.
Hence peer-to-peer.
The term client in the context of bittorrent simply means any participant in the network. In specs it's often used interchangeably with implementation and peer.
TCP connections are bidirectional. In bittorrent each stream consist of an endless flows of messages that is not in lockstep with the other direction. I.e. there is no request-response cycle.
Is it possible or is it normal to establish multiple connections to the same peer?
possible? yes, assuming the <source IP, source port, destination IP, destination port> tuple is distinct, which basically is what TCP demands.
But other implementations are likely to drop duplicate connections.
I have recently developed a GPRS communication software using Arduino (embedded application) and GSM modem to communicate to/fro from web server. However I found that there is enough delay and request getting dropped (response timeout) while receiving a response from server at client side.
The techniques I have tried are - TCP / UDP / HTTPS / HTTP.
In my case our requirement is for a Reliable, Fast, Guarantee Communication between client and server.
Please let me know which communication stack would establish the same or rather be best to be used?
Thanks in advance
GPRS gives you direct IP access to the Internet. If you're losing packets or suffering large delays when sending packets to your server then this sounds like a problem with the mobile ISP.
As Ken mentioned GPRS will provide you IP connectivity to the internet (or some private network if applicable).
On top of IP you can choose to use a number of higher layer protocols, the two most common of which are probably UDP and TCP.
UDP is 'connectionless' and provides very little in the way of error detection/correction etc.
TCP is connection orientated (which means that some signalling happens back and forth to establish a virtual 'connection' first). It also includes mechanisms to provide error detection, error correction and correct packet delivery order. TCP also includes flow control, to avoid the sender overloading the receiver, and congestion control to avoid network overload.
There is a perception that UDP is faster than TCP, but I think it depends on the situation - take a look at this discussion for some further discussion on speed, reliability etc between UDP and TCP (go down through all the high scored answers):
UDP vs TCP, how much faster is it?
For your requirements, I would think a solution based on TCP/IP is probably what you want.
Whether you want to use HTTP or some other protocol on top of that is going to be dependent on your solution, and to some extent on personal preference.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
I'm want to design a ruby / rails solution to send out to several listening sockets on a local lan at the exact same time. I want the receiving servers to receive the message at exact same time / or millisecond second level.
What is the best strategy that I can use that will effectively allow the receiving socket to receive it at the exact same time. Naturally my requirements are extremely time sensitive.
I'm basing some of my research / design on the two following articles:
http://onestepback.org/index.cgi/Tech/Ruby/MulticastingInRuby.red
http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm
Now currently I'm working on a TCP solution and not UDP because of it's guaranteed delivery. Also, was going to stand up ready connected connections to all outbound ports. Then iterate over each connection and send the minimal packet of data.
Recently, I'm looking at multicasting now and possibly reverting back to a UDP approach with a return a passive response, but ensure the message was sent back either via UDP / TCP.
Note - The new guy syndrome here with sockets.
Is it better to just use UDP and send a broad packet spam to the entire subnet without guaranteed immediate delivery?
Is this really a time sensitive component? If it's truly down to the microsecond level then you may want to ensure its implemented close to native functions on the hardware. That being said a TCP ACK should be faster than a UDP send and software response.
I am a newbie in network related aspects. I have few basic questions related to tcp/ip protocol and network
If a network switch (in a LAN network) between two PC's running Client and server (that are communicating through async. sockets) is powered down. Can the client and server will be notified that the socket connection is no longer active. Client and server are running on Win XP OS and are coded using C#.
Does network topology play a role in case of half open connection between socket client and socket server. For e.g. Will a disconnect status of either one or both be notified to other end and does it depend on network topology.
Thanks in advance.
A network element such as a router/hub/switch does not activly cause anything anything to happen on the TCP layer if it goes down. The operating system might notice that the physical layer is down and error out all sockets bound on that network card if it's a network element directly connected to the PCs that breaks - this will vary among operating systems/network cards and other things. Other than that, in order to detect that the connection has been severed, you'll have to send something and rely on the TCP timeout mechanisms to error out. This can be done implicittly by enabling TCP Keepalives on the connection.
A disconnect on one side will only be noticed if those messages reach the other side, if the network topology changes or sometinhg breaks in the middle of the connection in such a way that messages no longer reach the other end, a disconnect won't be noticed. (NAT gateways are a big source of problems such as this, they might time out a TCP connection they're tracking and you'll never know the connection is no longer valid unless you try to write something (or enable TCP keepalives) to the connection). Note that most networking APIs require that you Read from the connection to discovver that a the other end has closed the connection - assuming those "close" messages actually reach your side.