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.
Related
I am reading the documentation of Alexa Voice Service capabilities and came across the part on managing HTTP2 connection. I don't really understand how this down channel works behind the scenes. Is it using server push? Well, could server push be used to keep a long connection? Or is it just using some tricks to keep the connection alive for a very long time?
As stated on the documentation, the client needs to establish a down channel stream with the server.
Based on what I read here https://www.rfc-editor.org/rfc/rfc7540, From this state diagram:
once the stream sends a HEADER frame, followed by an END STREAM flag, the state will be half-closed(local) on the point of view of the client. So, this is how half-closed state for the device happened, as stated in above image. Correct me that if I am wrong.
For managing the HTTP connection, this is what it says.
Based on my understanding: the client sets a timeout of 60minutes for the GET request. After the request is sent, the server will not send any response. Then the connection will remain open for 60minutes. But once a response is sent from the server, the connection should be closed. Isn't that supposed to happen? Or, is it because when the server sends response through the down channel stream, it did not send an END STREAM flag so the stream will not be closed?
But once a response is sent from the server, the connection should be closed.
HTTP/1.1 and HTTP/2 use persistent connections, which means that a single connection can be used not just for one request/response, but for several request/response cycles.
Only HTTP/1.0 was closing the connection after the response, and so for HTTP/2 this is not the case, the connection will remain open until either peer decides to explicitly close it.
The recommendations about the idle timeouts are exactly to prevent the client to explicitly close the connection too early when it sees no network traffic, independently from requests or responses.
I'm building a distributed system and I would like asynchronous send and recv from both sides with blocking after high water mark.
PUSH/PULL sockets works great, but I wasn't able to bind a PUSH socket. Meaning I can't have a client-PUSH to server-PULL and a server-PUSH to client-PULL, if the client is behind a firewall, since the server can't connect to the client.
In the book, the following is written, but I can't find an example of it.
"REQ to DEALER: you could in theory do this, but it would break if you added a second REQ because DEALER has no way of sending a reply to the original peer. Thus the REQ socket would get confused, and/or return messages meant for another client." http://zguide.zeromq.org/php:chapter3
I only need a one-to-one connection, so this would in theory work for me.
My question is, what is the best practice to obtain asynchronous send and recv with ZeroMQ without dropping packets?
Most ZeroMQ sockets can both bind (listen on a specific port, acting as a server) and connect (acting as a client). It is usually not related to the data flow. See the guide for more info.
Try to bind on your servers PUSH socket and connect from your clients PULL socket.
In this article about Go Web Server, there're Listen Socket and Client Socket in Go,
I can't understand why GoLang need two sockets Listen Socket, Client Socket but not just one socket, can anyone explain its concept or give a metaphor?
EDIT : I update my answer.
Maybe I misunderstanding the graph or the graph isn't draw very well, possibly Listen Socket, Client Socket are same socket, if the socket hasn't accept connection from client, it's called Listen Socket, and after it accept the connection, it's renamed to Client Socket, there's only one socket with different stage and name.
UPDATE 1:
I find a better article and graph about Socket Working Here.
In the grpah of article, it's clear when there's new connection, TCP Server will
create a new socket to handle the connection, and the Listen Socket continuing listening for other connections.
Here's a paragraph in the article:
The first socket created by a TCP server, via NetSock_Open(), is typically designated a listen socket , and, after the call to NetSock_Listen(), remains open indefinitely, to allow the server to respond to various connection requests. Rather than using this socket to exchange data with requesting clients, the server will create a new socket for each request.
UPDATE 2
Since first update is working on Micrium, I find another seems more general TCP working instuction Here:
TCP connection flow The following sequence shows the flow of a TCP
connection:
The server creates the listener socket that is waiting for remote clients to connect.
The client issues the connect() socket function to start the TCP handshake (SYN, SYN/ACK, ACK). The server issues the accept() socket
function to accept the connection request.
The client and server issue the read() and write() socket functions to exchange data over the socket.
Note: There are several SSL APIs that you can use to send and receive data other than the read() and write() socket functions.
Either the server or the client decides to close the socket. This causes the TCP closure sequence (FINs and ACKs) to occur.
The server either closes the listener socket or repeats beginning with step 2 to accept another connection from a remote client.
Note: Normally after the accept() socket function ends, the server divides
into two processes (or threads). The first process handles the
connection with the client and the second process issues the next
accept() socket function. Figure 1 shows an example of a TCP
connection:
Note:
I find another Socker Programming Tutorial mention about working detail in TCP.
And In .NET Framework MSDN, the explanation about Socket.Accept Method() says Accept synchronously extracts the first pending connection request from the connection request queue of the listening socket, and then creates and returns a new Socket.
I have skimmed RFC about TCP before Update 1, but I didn't see it mention the detail that Listen use one socket, and when Accept it'll create another new Socket.
Maybe the thorough way is to research the Source Code about Create Socket and Connection in Go, but I'm not consiedring to do it now.
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 developed a chat server using websocket in cowboy, but I want to know if the message sent by server to client success.How can I know?
Websocket is a rather thin abstraction layer on top of a conventional TCP socket. After the initial handshake the difference is minimal. So, the question is: how do I know if a data chunk was received by the remote peer? The short answer: only if the peer acknowledges it explicitly by the means of application-level protocol. Remote client will send TCP ACK packets for every data packet you will send it, but this fact is well hidden from the application for good reasons. Receiving ACK packet only means that remote TCP stack has dealt with it, but says nothing about how (and if) the client application has processed it.
Add a special "acknowledge receive" message type to your chat protocol. Include a monotonically increasing sequence number in all of your outgoing messages, and include the SN of the received message in the ACK message to know exactly how much data the client has already processed.