According Gorilla Websockets Project it is not possible to send pings and pongs using golang.org/x/net/websocket. At the same time, the following is on the project page of golang.org/x/net/websocket:
Package websocket implements a client and server for the WebSocket protocol as specified in RFC 6455.
I am a little confused. golang.org/x/net/websocket implements RFC 6455 but can not send control frames (cancel, ping, pong) although this is specified in RFC 6455 - Section Control Frames
So what will happen if I use golang.org/x/net/websocket package. Will the connection abort after a timeout? In other words, how is it ensured here that the connection does not break off.
According Gorilla Websockets Project it is not possible to send pings and pongs using golang.org/x/net/websocket
The Gorilla README says something different. It says that the golang.org/x/net package cannot send a ping or receive a pong. It does not say that the package will not send a pong.
The golang.org/x/net package automatically responds to a ping received from the peer by sending a pong to the peer, as does the Gorilla package. Both packages work correctly with a peer that's using ping and pongs to keep the connection alive.
An application that uses the golang.org/x/net/websocket package cannot employ pings and pongs to keep the connection alive. There's no way to send the ping. There's no way to detect that the pong was received.
Related
There's a fantastic answer which goes into detail as to how REST apis work.
How do websockets work in the similar detail?
Websockets create and represent a standard for bi-directional communication between a server and client. This communication channel creates a TCP connection which is outside of HTTP and is run on a seperate server.
To start this process a handshake is performed between the server and client.
Here is the work flow
1) The user makes an HTTP request to the server with an upgrade header, indicating that the client wishes to establish a WebSocket connection.
2) If the server uses the WebSocket protocol, then it will accept the upgrade and send a response back.
3) With the handshake finished, the WebSocket protocol is used from now on. All communications will use the same underlying TCP port. The new returning status code, 101, signifies Switching Protocols.
As part of HTML5 it should work with most modern browsers.
I'm experimenting with Gorilla WebSocket Package and I would like to know whether there is a way based on the error retrieved from .ReadMessage to determine whether to start the Closing Handshake (ex. 1000 - normal closure) or stop the connection immediately (ex. 1006 - abnormal closure).
Currently what I'm doing is to store the list of error codes that I might use to close the websocket connection and if an error code is equals to one of the codes in my list, I do the Closing Handshake. However I'm not sure whether this complies with the WebSocket Spec.
Is there another way to do this or this is how it is suppose to be done?
Applications should only send close frames when the application decides to close the connection. The Gorilla package handles all other cases.
The Gorilla package sends the closing handshake on read errors. The Gorilla internal method handleProtocolError starts the closing handshake.
Gorilla replies to closing handshakes from the peer application.
According to the Wikipedia article: http://en.wikipedia.org/wiki/WebSocket,
The server sends back this response to the client during handshake:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Does this close the connection (as HTTP responses usually do) or it is kept open throughout the entire handshake and it can start sending WebSocket frames straight away (assuming that it succeeds)?
An HTTP socket going through the handshake process to be upgraded to the webSocket protocol is not closed during that process. The same open socket goes through the whole process and then becomes the socket used for the webSocket protocol. As soon as the upgrade is complete, that very socket is ready for messages to be sent per the webSocket protocol.
It is this use of the exact same socket that enables a webSocket connection to run on the same port as an HTTP request (no extra port is needed) because it literally starts out as an HTTP request (with some extra headers attached) and then when those headers are recognized and both sides agree, the socket from that original HTTP request on the original web port (often port 80) is then switched to use the webSocket protocol. No additional connection on some new port is needed.
I actually find it a relatively elegant design because it makes for easy coexistence with a web server which was an important design parameter. And, a slight extra bit of connection overhead (protocol upgrade negotiation) is generally not an issue because webSocket connections by their very nature are designed to be long running sockets which you open once and use over an extended period of time so a little extra overhead to open them doesn't generally bother their use.
If, for any reason, the upgrade is not completed (both sides don't agree on the upgrade to webSocket), then the socket would remain an HTTP socket and would behave as HTTP sockets normally do (likely getting closed right away, but subject to normal HTTP interactions).
You can see this answer for more details on the back and forth during an upgrade to webSocket: SocketIO tries to connect using same port as the browser used to get web page
We are building a large slanger cluster and would like to use websocket TCP as client connectivity indicator, so whenever a client is offline we could tell from the channel state. Is there an API to check online/offline status of a channel?
Besides that, is there a way to get the TCP fd of the websocket beneath a channel? So I can grab some statistics of that long connection.
OK after reading through Slanger's source code I have concluded that it is not possible. I modified slanger/lib/subscription.rb to have my own customized tcp status exposed via http api.
I'm using the HTTPClient gem (http://github.com/nahi/httpclient) for ruby, to post data to IIS 6.1. Even though both support HTTP 1.1 it seems to be closing the socket after each request made, rather than using persistent connections. I haven't added any flags to enable persistent connections (mainly because having poked about the source code it appears that they should be enabled by default).
The reason I think the socket is being close is that if I watch the requests in Wireshark once each request is made I see FIN/ACK TCP packets sent from the client to the server, then the same sent back the other way.
Am I misreading that or does that mean the socket is being closed?
Wikipedia's article on TCP suggests that the FIN/ACK packets are a signal to terminate the connection. Check which of the client or server initiated the sending of the FIN packet - that's the party requesting that the connection is closed.
As you saw in the source, an HTTP 1.1 implementation should assume that connections are persistent by default.
Is the client specifying HTTP 1.1 in its request and is the server responding accordingly?