i used socket.io and node.js for server and i used unity socket.io for client in my game.
now, my question is, How can I be notified when client missed receive acknowledge.
for example, client emit this:
socket.Emit("testClient", data,ackCallBack);// client emit testClient to server
// get acknowledge in this callback method
public void ackCallBack(JSONObject data)
{
Debug.Log("---------ackCallBack----------" + data);
}
but i cant detect if acknowledge missed.
How to solve this problem.
I don't know much about client/server architectures but I believe socket.io use TCP, therefore if a packet is lost it is sent again.
Again I'm not 100% confident about this subject, wait for network guru to come by x)
Related
I have a proxy server implemented, after sending the final response to client if I directly close the socket (System.Net.Sockets TCPClient.Client.Close()) then client end receives connection aborted error but instead if I use System.Net.Sockets TCPClient.getStream().Close(), it works successfully.I want to understand what's the difference and why is client side receiving an error in the first scenario?
I would say, that Close of sockets is not trivial operation as most people think :)
First of all, you should understand the how the close should be done correctly. Basically, you have to consider that close is a kind of message like any other message sent out your socket. Or other words close() is an information on the other side of communication that the peer finished some kind of work.
Now the important thing to understand that having a TCP socket you can inform the peer that you finished sending or finished listening.
On this page, you can check out how it works in the background (note that ACK and FIN are IP layer messages so even using plain sockets implementation you will never see them): http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
So now the more practical step. Please consider that you have a client and server. The server needs to receive a message and close the connection. Please consider that client is just going to send a message and then closes the connection. If you will also consider that networks need some time to process your communication, you will realize that if you do it quickly, client will close the connection before server received your message. If you can the TCPClient.Client.Close() client will stop listening for anything (that means also for information about that the server closed the connection). So here comes the TCP stack to play (windows does it for you) - in case you will close this way the socket, TCP stack, needs to inform the server site that whatever server has sent goes to dump. So that's why you have an exception.
So the correct way is to:
inform the server that client finished sending any data (FIN)
wait until server confirms that he knows that client will not send any data (ACK)
now server should inform client that will stop sending data (FIN)
now the client can say - "ok I got it, I will not listen anymore" (ACK)
Anyway, the C# TCPClient seems to hide the logic of the background socket closing routine, but if you will not call the close sequence correct way, you'll end up with errors.
I hope that this little bit long explanation will help you understand how it works in the background and finally let you understand why.
It's also a good way to read more about TCP protocol details if you wish to learn more: http://www.tcpipguide.com/free/t_TCPIPTransmissionControlProtocolTCP.htm
I suppose that in order to close connection, you need to send some special bytes sequence. And looks like it is implemented only by tcpclient library , and not implemented by socket library. Probably something like Eof should be sent.
You may check it by some net traffic utilities like tcpdump.
Good luck!
I'm starting to use golang for a quite amount of time for a project. In my project I have to implement a tcp server which responds to tcp clients. The server has to send a number of messages to a client.
The problem is that when a server writes a message to a client connection, it has to wait until the client has read that message from buffer and then send another message (the server has to wait until the client calls the reader.ReadString('\n') method).
In my server code I wrote:
for {
data := <-client.outgoing
client.writer.WriteString(data + "\n")
client.writer.Flush()
}
but the server sends all the messages to client without waiting for ReadString in client.
How to make server wait until the client read a message and then send the other message?
I think that either the assignment is ambiguous or you're misinterpreting it and solving the XY problem.
The short answer is that you can never know whether the client has read a message just by looking at the TCP conversation. You have to implement this "protocol" in your application.
Here are a few problems:
From your application you don't really have access to what TCP is doing. You get a stream on which you can perform I/O.
The fact that a write to your stream "succeeds" only means that TCP has agreed to try to transport your stuff and has an independent copy. It doesn't say anything about whether the data has been received and it doesn't even mean the data has been even sent
You may find certain mechanisms to peer into TCP's inner workings (such as ioctls, SIOCINQ, SIOCOUTQ or various setsockopts): these won't help
Even if you find out what your TCP is doing, this only tells you what the remote TCP is doing. So if you have full control over your TCP and even see the acknowledgments from the peer, you still don't know what the application is doing. It's very possible the application didn't read the data yet (it might not have requested the data, the TCP might be withholding it in a buffer for some weird reason, the scheduler might not have scheduled the remote process etc.)
Going back to your question, a way to really know whether the remote application has received your message is to have the remote application tell you. This means you have to restructure your protocol to:
Send stuff from the server
Wait for a message from the application telling you it received your stuff
Send more stuff (because you know from point 2 it's safe to do so)
I am building an OSX app that needs to get data from server. The easy way, is to make a GET request at some fixed time interval, and process results. Thats not what I want. I want the other way around: e.g. server to send data to my app, when something happens on the server side. That way I do not need to make constant requests from client side. I don't need the data to visually be displayed, just processed.
Can this be implemented in OSX with Swift?
You have two ways to achieve this:
Websocket:
Websocket is a full-duplex communication channel over a TCP-Connection. It's established via HTTP.
Long Polling:
Same as you said before but without responding directly. Your client makes a HTTP request and set a very long timeout timer. The server responds after something is happening. (More)
I would recommend you Websocket since it was built exactly for this use case. But if you have to implement it quickly you should probably go with long polling for now, since the barrier to implement it is much lower and switch to Websocket later.
Can i avoid putting a timed event from client app which pings server, for event updates?
I am using Angularjs, Nodejs-expressjs, to build my web app.
The other alternative i can think of maybe socket.io.
Can i do something like
app.post('/abc', function(req, res){
if(event){
res.send('event data');
}
});
The above app.post will not return till the event happens.
There are multiple ways to implement push notifications:
HTTP Long Polling : The client initiates a request. The server checks if it has any new notifications. Irrespective of whether or not it has new notifications appropriate response is send and connection is closed. After time X client initiates another request (+ Very easy to implement - notifications are not real time. They depend on X since data retrieval is client initiated. As X decreases overhead on server increases )
HTTP Streaming: This is very similar to HTTP Long Polling however the connection is not closed. The server sends chunked response. So as soon as server receives new notification that it wants to push it can simply write to the socket. ( + lower latency than long polling and almost real time behaviour / overhead of closing connection and re opening reduced - memory usage client side keeps on piling up / ugly hacks etc )
WebSocket: TCP based protocol provides true two way communication. The server can push data to client any time. ( + ve: true real time - some older browsers dont support it ). Read more about it WebSocket.org | About WebSocket
Now based on the technology stack there are various solutions available: (A) Nodejs : the cross-browser WebSocket for realtime apps. ( does heavy lifting for you. Gracefully falls back in case websocket is not supported ) (B) Django : As mentioned previously you can use signals for notifications. Also you can try django-websocket 0.3.0 for supporting websocket (C) Jetty / Netty and Grizzly (Java based) : All have websocket support
from link
I'm new to node.js and I want to ask a simple question about how it works.
I have used FMs in the past for client to client communication and real time applications. For example, for creating a collaborative application where you need to see what other users are doing. I want to explore that using NodeJS.
I have couple of questions:
1) How does NodeJs handle server-to-client communication? Is thee any way to push information to the client? or the client needs to be making requests constantly to the server to see if anything has changed?
2) Is there such thing like permanent connections between the server and the clients?
3) How Can be handle client-to-client communication (of course thru the server)?
Thanks in advance.
3) How Can be handle client-to-client
communication (of course thru the
server)?
A simple solution is to open a websocket between the server and each client :
[Client A] <==websocket==> [Server] <==websocket==> [Client B]
If you go with Socket.IO for example, it is very easy to do client-to-client communication this way.
When the server receives a message from one client, you just broadcast it to all clients or send it to one specific client depending on your use case.
Some example code using Socket.IO :
var socket = io.listen(server);
socket.on('connection', function(client) {
client.on('message', function(msg) {
broadcast(msg); // broadcast message to all clients
// OR
socket.clients[session_id].send(msg); // send message to one client
});
client.on('disconnect', function( ) {
console.log('Client Disconnected.');
});
});
Quite a lot of Node.js questions from you recently ;)
As Toby already said, Node can do HTTP, TCP/UDP and Unix Sockets. When you establish a permanent connection, you can of course push data to the clients.
Since you are talking about Browser based clients, there a numerous ways to achieve this. You could for example use WebSockets with a Flash fallback. In case you are not interested in the low level details and want a complete package, take a look at Socket.IO.
WebSockets can't do this, Flash can't do it either as far as I know. So unless you want to enter Java/Silverlight land, you'll need to route the requests through your server.