I have created a php websocket server, and a php websocket client, the websocket client communicate with the server using JSON format, each message means an operation to handle by the websocket server.
when running both the client and the server in localhost I can reach about 35 operations/sconds, and the same results when running both client and websocket server on the production server, but running client in locahost (my machine) with production websocket server (remote) that only results in 5 operations/seconds.
What could be the reason behind that bad performance when using remote websocket server?
Solved by changing websocket client app logic (sending messages asynchronously instead of synchronously), by using that approach we have increased the score to more than 100 operations/s.
Credits to Jérôme Richard (See the question comments)
Related
Websockets are hailed as a bi-directional process. However, whilst there are hundreds of websocket code examples on the web, they all require a request from the client(browser) to the server to get the data (like an echo server or chat).
So far, I have not found any code which will send new data (originating at the server end) to the client via an open websocket. Ideally, I would like to use a node.js server but I'm open to alternatives. Any ideas?
I was experimenting hashicorp/yamux over gorilla/websocket, and got stuck.
I started with vanilla WebSocket using the echo example from Gorilla WebSocket project. It was very a straight forward client-server setup. Then image that the server is now behind a firewall, thus the client cannot make a direct connection to it. So I introduced a hub and an agent. The hub is supposed to be publicly visible and connectable for the client. The agent would run alongside the server, who would first make a WebSocket connection to the hub and then multiplex the connection using Yamux so that the hub can then initiate requests to the server. In this way, I effectively "exposed" the server beyond the firewall.
For normal HTTP endpoints, things are good. The client can make requests to the hub, who would proxy these requests to the agent using the WebSocket connection initiated by the hub, and then the hub would further proxy these requests to the server.
However, this trick failed to work with WebSocket endpoints. For the echo example, the client can access the HTML on / through the hub-agent-server chain, but would fail on the /echo path, which is a WebSocket endpoint.
My question is, is this WebSocker over Yamux over WebSocket fundamentally impossible, or do I just need some extra lines to get things work? Here's the code I've been experimenting with. Really appreciate your helps!
wss://www.mysite.ca/socket.io/?EIO=3&transport=websocket
This is how chrome webdevoloper tools shows the request url of a socket io.
I am trying to understand more about EIO=3&transport=websocket .
I have to invoke the url from an API tool
These are query parameters that the socket.io client sends to the socket.io server as part of the initial connection request.
EIO=3, I believe, is the version number of the engine.io sub-system in socket.io. If the server is not compatible with this version number, it will likely fail the attempt to connect.
transport=websocket says that socket.io wants to use the websocket protocol as the eventual transport. socket.io has several different transports it supports including web polling and a flash-based protocol.
To connect to socket.io server, you will need a full-fledged socket.io client. You can't make a socket.io connection by just sending a URL from a tool to the server. There's a lot more involved than that in establishing a working socket.io connection.
My application consists of two pieces: WebSocket server - which is hosted on OpenShift DIY cartridge; WebSocket client - which connects to my server from home PC. WebSocket server is written using embedded Jetty and its library for WebSockets. Client side is written using JAVA and Tyrus library. It works pretty well except for one glitch that I cannot explain.
When running WebSocket server on OpenShift DIY cartridge, WebSocket connection gets dropped every 2 min. Connection drops happen quite precisely so obviously it is not related to potential network outages. Besides I have tested exactly the same application on Heroku and there were no connection drop. Moreover onClose(...) method receives NORMAL_CLOSURE close code.
I am almost sure that OpenShift Apache layer closes idle WebSocket connections every 2 min. even though WebSocket client sends Ping messages and receives Pong messages from the server. Has anyone experienced this type of WebSocket connection drops? Are there are parameters I can use to prevent connection drops?
Thank you in advance.
Update: I added a dedicated thread on the server side to send Pong messages to the client (Jetty does not support Pong handlers yet so I cannot use Ping messages) and drops disappeared. It seems like OpenShift Apache layer started treating connection as "alive" and does not close it. Then I noticed one more strange behavior: someone ping my server side application via HTTPS every hour. HTTP headers look like this:
HTTP/1.1 HEAD /
Accept: /
User-Agent: Ruby
X-Forwarded-Proto: https
X-Forwarded-Host: ....rhcloud.com
Connection: keep-alive
X-Request-Start: t=1409771442217677
X-Forwarded-For: 10.158.21.225
Host: wsproxy-gimes4dieni.rhcloud.com
X-Forwarded-Port: 443
X-Client-IP: 10.158.21.225
X-Forwarded-SSL-Client-Cert: (null)
X-Forwarded-Server: localhost
I do not use Ruby, I am using only HTTP and IP address is different from my regular requests. Does anybody has a clue whether this is some sort of OpenShift "service" of this is coming from the Internet?
SSH into your project, open ~/haproxy/conf/haproxy.cfg with a text editor such as vi and edit timeout queue,timeout client, and timeout server to whatever you want. I set mine to 5m, which is 5 minutes. After you have made the changes, exit and run
~/haproxy/bin/control restart
Now your websocket timeout should be set.
The WebSocket standard hasn't been ratified yet, however from the draft it appears that the technology is meant to be implemented in Web servers. pywebsocket implements a WebSocket server which can be dedicated or loaded as Apache plugin.
So what I am am wondering is: what's the ideal use of WebSockets? Does it make any sense to implement a service using as dedicated WebSocket servers or is it better to rethink it to run on top of WebSocket-enabled Web server?
The WebSocket protocol was designed with three models in mind:
A WebSocket server running completely separately from any web server.
A WebSocket server running separately from a web server, but with traffic proxied to the websocket server from the web server (allowing websocket and HTTP traffic to co-exist on the same port)
A WebSocket server running as a plugin in the web server.
The model you pick really depends on the application you are trying to build and some other constraints that may limit your choices.
For example, if your application is going to be served from a single web server and the WebSocket connection will always be back to that same server, then it probably makes sense to just run the WebSocket server as a plugin/module in the web server.
On the other hand if you have a general WebSocket service that is usable from many different web sites (for example, you could have continuous low-latency traffic updates served from a WebSocket server), then you probably want to run the WebSocket server separate from any web server.
Basically, the tighter the integration between your WebSocket service and your web service, the more likely you will want to run them together and on the same port.
There are some constraints that may force one model or another:
If you control the server(s) but not the incoming firewall rules, then you probably have no choice but to run the WebSocket server on the same port(s) as your HTTP/HTTPS server (e.g. 80 and 443). In which case you will have to use a web server plugin or proxy to the real WebSocket server.
On the other hand, if you do not have super-user permission on the server where you are running the WebSocket server, then you will probably not be able to use ports 80 and 443 (below 1024 is generally a privileged port range) and in that case it really doesn't matter whether you run the HTTP/S and WebSocket servers on the same port or not.
If you have cookie based authentication (such as OAuth) in the web server and you would like to re-use this for the WebSocket connections then you will probably want to run them together (special case of tight integration).