I want to determine the ping of a socket.io server without actually creating a socket. Why? Because I have a bunch of socket.io servers, and I want the client to connect to the one with the lowest latency and I don't want to manage all those sockets. Plus i think creating a socket and closing it on every single server just for a simple ping does not make sense and would cause performance problems.
Ideally, the client would create a websocket just for each ping (i think i know how to do that). But on the server side, what is the best way to receive those websocket messages (made with ws://), since you don't typically make/receive direct ws requests with socket.io (as all of that stuff is handled under-the-hood)?
Use the ping class.
Ping ping = new Ping();
PingReply reply= ping.Send("www.google.com");
Console.WriteLine(reply.RoundtripTime.ToString() + "ms");
As done here, too: Making a "ping" inside of my C# application
Related
I have a Websocket connection being served from http-kit (Clojure, and it works great). I send pings from the client to make sure we're still connected, and everything works fine there. My question is, do people bother pinging client from server in these cases?
I was trying to set something up to remove the channel from the server if I didn't get a response, but it's not very functional-friendly to set up timed processes and alter state to track the ping-pong cycle, so it was getting a little ugly. Then I thought, the server can handle hundreds of thousands of simultaneous connections, should I just not worry about a few broken threads? How do people typically handle (or not handle) this?
The WebSocket protocol itself has heart beating to keep the connection alive. If you wanted an additional layer on top of that you could use the STOMP protocol, which coordinates heartbeats between client/server.
The one STOMP implementation I know of for the JVM is Stampy. There’s one for JS too, stompjs. Note: the heartbeat implementation differs between these libs, I believe the Stampy one is incorrect. You’d have to roll your own.
I am trying to tunnel websockets over TCP. I know how to tunnel HTTPS - "Connect URL:port" is where I start. From there, one opens a socket to the target and then just pipe between the client and the target. Where do I start with websockets? is there something similar to a "Connect url:port" to begin with, which I can catch in my http server and then do some upgrade processing?
You sure you want to tunnel WebSocket over TCP? WebSocket runs over TCP.
I think you mean you want to tunnel TCP traffic with WebSocket, i.e., take an existing, traditional Socket-based application and make it work over the web. If that's what you mean, you essentially put your TCP data in a WebSocket frame and on the receiving end you read the WebSocket frame and extract the data. Of course this is easier said than done. You have to make sure you create the WebSocket frame correctly on the sender side (also handling the TCP data stream, which also may be tricky), encrypt the data (its going over the web, right?) and on the receiving side read the WebSocket frame, extract the data from the right parts of the frame. And also you need to check to see if all the data is in one WebSocket frame or multiple frames.
As I said, its not dead simple.
There are several WebSocket libraries out there that may (or may) not handle all of this for you (many do not handle the multiple WebSocket frame situation).
I tried to write a game server with ZMQ sockets. The server is using a ZMQ_REP socket and the client a ZMQ_REQ socket.
This works only if one client is connected. If I connect a second client then communication breaks between the server and the first client.
Which server <-> client pattern works for one server and multiple clients?
for servers, you want to use ROUTER, and for clients, DEALER. There are a lot of examples of this in the ZeroMQ Guide. It's worth reading through that (or buy the book) and learning the different patterns, as you try simple models of your own. Don't try to build anything too complex to start with.
How can a client both subscribe and listen to replies with zeromq?
That is, on the client side I'd like to run a loop which only receives messages and selectively sends requests, and on the server side I'd like to publish most of the time, but to sometimes receive requests as well.
It looks like I'll have to have two different sockets - one for each mode of communication. Is it possible to avoid that and on the server side receive "request notifications" from the socket on a zeromq callback thread while pushing messages to the socket in my own thread?
I am awfully new to ZeroMQ, so I'm not sure if what you want is considered best-practice or not. However, a solution using multiple sockets is pretty simple using zmq_poll.
The basic idea would be to have both client and server:
open a socket for pub/sub
open a socket for req/rep
multiplex sends and receives between the two sockets in a loop using zmq_poll in an infinite loop
process req/rep and pub/sub events within the loop as they occur
Using zmq_poll in this manner with multiple sockets is nice because it avoids threads altogether. The 0MQ guide has a good example here. Note that in that example, they use a timeout of -1 in zmq_poll, which causes it to block until at least one event occurs on any of the multiplexed sockets, but it's pretty common to use a timeout of x milliseconds or something if your loop needs to do some other work as well.
You can use 2 threads to handle the different sockets. The challenge is that if you need to share data between threads, you need to synchronize it in a safe way.
The alternative is to use the ZeroMQ Poller to select the sockets that have new data on them. The process would then use a single loop in the way bjlaub explained.
This could be accomplished using a variation/subset of the Majordomo Protocol. Here's the idea:
Your server will be a router socket, and your clients will be dealer sockets. Upon connecting to the server, the client needs to send some kind of subscription or "hello" message (of your design). The server receives that packet, but (being a router socket) also receives the ID of that client. When the server needs to send something to that client (through your design), it sends it to that ID. The client can send and receive at will, since it is a dealer socket.
Is this chat using "long polling" or "http streaming" ?
http://go-mono.com/moonlight/chat.aspx
It's not anything that simple. It uses http://www.mibbit.com/chat, which is a full IRC client written in Javascript and Java. Blog at http://blog.mibbit.com/.
Edit: Here's your answer.
The first part I got working was the communications between browser and server. That’s done using 2 XMLHttpRequests. The first one is simply to send data from browser to server. It utilizes keep-alive, to minimise new connections.
The second XHR is the ‘receive lazy polling’ one. It connects to the server, and the server holds it open until there are messages available, or a timeout expires. This one is also keep-alive, so the next request goes down the same connection.
What you end up with is 2 connections held open to the server, with packets (json in this case), and some http headers from time to time.
To make sure the server would scale, I wrote a custom webserver in java using nio. It handles all of the connections in a single thread and as I say, scales to tens of thousands of connections.
If the client requests a new connection, it sends a request to the webserver, which then connects out, and starts proxying etc. It also runs an ident server in the case of irc connections so that an irc server can identify individual browsers. I looked at existing frameworks etc to do this sort of thing, but I valued learning how it all works, and thought that my use case may be specific enough to be able to optimise more than general frameworks can.