I've an application that's using Apache mina library for communicating based on TCP. The apache mina library provides a callback with IOBuffer that contains data coming over the network, however often times the data is received out of order or redundantly. I skimmed through the TCP protocol and it says that the protocol always ensures delivery of the data in correct order. The company that provided the APIs for their server claim that they are using TCP/IP for sending the response back however before sending the response back their server doesn't care about confirming if the client (in this case my application/apache mina library) is connected to the server. So the server just fires off the message and moves on.
If I'm not mistaken, that's the UDP protocol's behavior. My question is, if the server is using TCP for sending the response back:
Why do I get out of order data (it's rare but happens one in a while)?
How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?
Is this really TCP or UDP or some variation of TCP protocol?
Apache Mina does asynchronous messaging over the top of various transports including TCP.
Since Mina is asynchronous, out-of-order delivery should be expected.
Why do I get out of order data (it's rare but happens one in a while)?
One possible explanation is that multiple TCP streams are being used. Data delivered using one TCP stream will be delivered in order, but if multiple streams are used, data in one stream could "overtake" data on another stream, in the TCP stacks on the sending or receiving end, on the network, or in the client side library.
How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?
Because ... reliable delivery is not a basic attribute of Mina.
If you are using Mina to talk to a service with a particular application protocol, then that protocol will determine will determine whether "sending the data before checking the receiver is connected" is allowed / will work or not. For example, it won't for an HTTP response, because an HTTP response is sent on a connection that was previously established to send the request.
Actually, it seems that there are a variety of ways to use Mina. Some involve an application protocol; e.g. see HttpClientCodec and HttpServerCodec. Others don't.
Is this really TCP or UDP or some variation of TCP protocol?
If they say that TCP is being used as transport, then it is. However, Mina is neither TCP or UDP. It is Mina. It hides the details of the transport.
Bottom line, if you want the reliability / in-order delivery properties of TCP/IP, you should probably use them directly. Mina is providing higher performance than conventional TCP/IP over a synchronous socket by relaxing the normal properties of a (single) stream-based transport.
Related
I want to write a program in java that handles two way communication between server and client using udp.Most of the sources online specify only one way,that is from client to server.I want the server to be able to send messages to the client as well.
If you cannot use TCP, you can still achieve the same behaviour with UDP.
There are three aspects to consider.
First, that you mentioned: you want to communicate both ways. You can do that by running a sender and a listener thread on both the client and the server.
Second: UDP packets are not guaranteed to arrive. You have to implement an ACK logic in your application layer.
Third: UDP packets are not guaranteed to arrive in order. You have to implement some kind of ordering in your application layer.
UDP is a connection-less protocol on top of IP. This just means that there is no established connection you receive on the other end, you just receive packets of data. To answer back, you have to send a packet "back" to the client.
For this the client needs to be reachable however. This might or might not work through firewalls. Usually firewalls get "punched through" if the client initiates the conversation, but there is no guarantee.
Note also, that UDP packets may arrive out of order, duplicated or not at all. You have to be ready for all. If you send bigger (than MTU) packets, they may have a higher chance of not arriving due to splitting.
I'm currently developing a Java WebSocket Client Application and I have to make sure that every message from the server is received by the client. Is it possible that I lose some messages (once they are sent from the server) due to a connection interruption? WebSocket is based on TCP so this shouldn't happen right?
It can happen. TCP guarantees the order of packets, but it does not mean that all packets sent from a server reach a client even when an unrecoverable trouble happens in an underlying network. Imagine someone pulls out your LAN cable or switches off your WiFi access point at the worst timing while your application is communicating with your server. TCP does not overcome such a trouble.
To ensure that every WebSocket message sent from your server reaches your client, you have to implement some kind of SYN/ACK in the application layer.
TCP is a guaranteed protocol - packets will be received in the correct order by the higher application levels at the far end (this is as opposed to UDP which is a send and hope protocol).
Generally speaking TCP should be be used for connections where all the data must arrive correctly at the far end. UDP is used where a missing packet can be dropped without significant issue (e.g. streaming services, NTP updates)
In my game, to counter missed web socket messages, I added an int/long ID for each message. When the client detects that something is wrong in the sequence of IDs it receives, the client will request for new data from the server to be able to recover properly.
TCP has something called Control Flow- which means it provides reliable, ordered, and error-checked delivery.
In other words TCP is a protocol that checks constantly whether the data arrived.
This protocol has different mechanisms to ensure that.
You can see the difference between TCP and UDP (which has no control flow) in the link below.
Difference between tcp and udp
I need to implement client/server instant messenger using pure sockets in Java lang.
The server should serve large number of clients and I need to decide which sockets should I use - TCP or UDP.
Thanks, Costa.
TCP
Reason:
TCP: "There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent."
UDP: "There is no guarantee that the messages or packets sent would reach at all."
Learn more at: http://www.diffen.com/difference/TCP_vs_UDP
Would you want your chat message possibly lost?
Edit: I missed the part about "large chat program". I think because of the nature of the chat program it needs to be a TCP server, I cannot imagine the actual text content sent by users over a UDP protocol.
The max limit for TCP servers is 65536 connections at the same time. If you really need to go past that number you could create a dispatcher server that would send incoming connects to the appropriate server depending on current server loads.
You could use both. Use TCP for exchanging the actual messages, (so no data lost and streaming large messages, (eg. containing jpegs etc), is possible. Use UDP only for sending short 'connectNow' messages to clients for which there are messages queued. The clients could have states like (NotLoggedIn, TCPconnected, TCPdisconnected, LoggedOut) with various timeouts to control the state transitions as well as the normal message-exchange events. The UDP 'connectNow' message would instruct clients in 'TCPdisconnected' to connect and so move to 'TCPconnected', where they would stay, exchanging messages, until some inactivity timer instructs the client to disconnect for now. This would, of course, be unreliable and so you may wish to repeat the 'connectNow' message every X seconds for N times until the client connects. The client should, in any case, attempt a poll every X minutes, just in case...
It depends whether the user needs to know if the messages have been delivered to the server. UDP packets have no inherent acknowledgement. If the client sends an IM message to the server and it gets lost in transit, neither the client or the server will know about it.
(The short answer is "use TCP" ... but it is worth thinking through the design implications for yourself.)
TCP would give you reliability, which is certainly desirable when during instant messaging -- you would not want messages to be dropped during converstation.
However, if you intend on using group messaging, then you might end up using mulitcast. For such cases, UDP would be the right chioce since UDP can handle point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers. One alternative could be to use TCP for point-to-point chat and use UDP for group messaging.
We are building a new client along with a caching proxy component for an existing online game. The current setup looks like:
Server
| \
TCP TCP
| \
Client1 Client2
The new setup will be:
Server
| |
TCP TCP
\ \
Proxy <-- (New!)
| \
0MQ 0MQ
| \
Client1 Client2 <-- (New!)
The proxy component will sit close to the existing game server and speak the old line based TCP protocol to it, while speaking a new Google Protocol Buffers-based protocol over 0MQ to the new client. In addition to forwarding and translating messages between the server and its clients, the proxy will also cache (protobuf) messages destined for clients.
The server responds to client requests, but may also send unsolicited messages to specific clients, or to all clients. Since the proxy will maintain a cache of messages destined for a certain client, it needs to keep some state associated with each client.
I've been reading quite a bit in the ZeroMQ Guide, but I'm still not sure which of its "patterns" or socket combinations would suit this setup best. I'm hoping there's some ZeroMQ wizard out there who can give some advice on what the best way to go here is.
The question is not language specific, but the proxy component will be written in Java and the client in C#.
Many thanks in advance!
I think the Asynchronous Client Server pattern will get you close. Each of your clients creates a DEALER socket which connects to the ROUTER socket in your proxy. Review the example Java source. You could base your proxy on the ServerTask class, using the frontend/ROUTER socket and omitting the backend/dealer socket.
Your server will be able to respond to client requests and send unsolicited messages back to any client. You will need to cache the socket id of each client after the client has sent at least one message.
Your TCP connection to the game server is conceptually similar to the backend DEALER sockets between the server and workers - however since your connection is classic TCP and and not ZeroMQ you cannot use ZeroMQ sockets and will need to do something custom. And your custom solution requires that you not violate ZeroMQ's concurrency rules, when you integrate with classic TCP sockets.
Here is one way - use a set of PAIR sockets (lets call them A and B) and a BlockingQueue to act as a bridge between ZeroMQ and your TCP sockets. And create 3 threads - TCPRead, TCPWrite and ZeroMQ.
TCPRead reads from the TCP connection to the game server. It converts them to protobuf messages and forwards them through the A socket.
TCPWrite polls the BlockingQueue for messages. When it receives a message it converts it and sends it to the game server via TCP connection.
Finally, most of the work is in the ZeroMQ thread. It uses ZeroMQ polling and is constantly polling it's router socket (for all messages from all clients) and the B socket (for messages from the game server). Sending messages to a client is straightforward and is handled by sending the message to the router socket, prefixing the message with the socket id of the client. Sending messages to the server is done by adding a message to the BlockingQueue. It will be picked up by TCPWrite and forwarded to the game server.
Once you get this basic design working, you can go nuts and add workers etc as described in the various patterns.
Hope this helps.
You can also use 0MQ ROUTER sockets in raw mode, meaning you could write the proxy with two ROUTER sockets. I'd stay away from PAIR sockets except for parent-to-child thread pipes.
It takes a while to plough through the ZeroMQ documentation, excellent as it is. I did and came to the conclusion that Asynchronous Client-Server was close to what I initially wanted.
But it wasn't quite. So I then proceeded to build.
What I actually wanted is based on what I'd learnt from the various examples. A full description of what I ended up with is in here as is the code which may be of some use, for reference or as an actual library.
I have written a socket program in Java. Both server and client can sent/receive data to each other. But I found that if client sends data to server using TCP then internally TCP sends acknowledgement to the client once the data is received by the server. I want to detect or handle that acknowledgement. How can I read or write data in TCP so that I can handle TCP acknowledgement. Thanks.
This is simply not possible, even if you were programming in C directly against the native OS sockets API. One of the points of the sockets API is that it abstracts this away for you.
The sending and receiving of data at the TCP layer doesn't necessarily correlate with your Java calls to send or receive data. The data you send in one Java call may be broken into several pieces which may be buffered, sent and received independently, or even received out of order.
See here for more discussion about this.
Any data sent over a TCP socket is acknowledged in both directions. Data sent from client to server is the same as data sent from server to client as far as TCP wire communications and application signaling. As #Eric mentions, there is no way to get at that signaling.
It may be that you are talking about timing out while waiting for the response from the server. That you'd like to detect if a response is taking too long. Is it possible that the client's message is larger than the server's response so the buffering is getting in the way of the response but not the initial request? Have you tried to use non-blocking sockets?
You might want to take a look at the NIO code if you have not already done so. It has a number of classes that give you more fine grained control over socket communications.
This is not possible in pure Java since Java's network API all handles socket, which hides all the TCP details.
You need a protocol that can handle IP-layer data so you can get TCP headers. DLPI is the most popular API to do this,
http://www.opengroup.org/onlinepubs/9638599/chap1.htm
Unfortunately, there is not Java implementation of such network. You have to use native code through JNI to do this.
I want to detect or handle that acknowledgement.
There is no API for receiving or detecting the ACKs at any level above the protocol stack.
Rethink your requirement. Knowing that the data has got to the server isn't any use to an application. What you want to know is that the peer application has received it, in which case you have to get the peer application to acknowledge at the application protocol level.