Can you discern on the server side which transport method is being used for a given SignalR connection? (WebSockets, SSE, long polling, etc.?)
Inside a Hub you can detect the transport being used by looking at the request's query string:
Context.QueryString["transport"]
This will evaluate to "webSockets", "serverSentEvents", "foreverFrame" or "longPolling".
Ideally your code should not depend on which transport is being used since SignalR abstracts that for you. However, this could be useful for logging and such.
For ASP.NET SignalR version 2.0, you can use $.connection.hub.transport.name to print out the name of the transport. It will evaluate to "serverSentEvents" and other transports.
Related
On the engine.io website it says:
Engine.IO is the implementation of transport-based
cross-browser/cross-device bi-directional communication layer for
Socket.IO.
What does "transport-based" mean? I presume simply that it uses TCP?
It means the ability to use different underlying transports to support the Socket.IO api. The two core transports that it uses are polling: XHR / JSONP polling transport, and websocket: WebSocket.
From the docs:
The main premise of Engine, and the core of its existence, is the
ability to swap transports on the fly. A connection starts as
xhr-polling, but it can switch to WebSocket.
The central problem this poses is: how do we switch transports without
losing messages?
Located here
For a while now I have been implementing a RESTful API in the design of my project because in my case it is very useful for others to be able to interact with the data in a consistent format (and I find REST to be a clean way of handling requests). I am now trying to not only have my current REST API for my resources, but the ability to expose some pieces of information via a bidirectional websocket connection.
Upon searching for a good .net library to use that implements the websocket protocol, I did find out about SignalR. There was a few problems I had with it (maybe specific to my project?)
I want to be able to initialize a web socket connection through my
existing REST API. (I don't know the proper practice to do this, but
I figured a custom header would work fine) I would like them (the
client) to be able to close the connection and get a http response
back (101?) to signify its completion.
The problem I had with SignalR was:
that there was no clean way outside of a hub instance to get a user's connection id and map it to a external controller where the rest call made affects what piece of data gets broadcasted to the specific client (I don't want to use external memory)
the huge reliance on client side code. I really want to make this process as simple to the client and handle the majority of the work on the server side (which I had hoped modifying my current rest api would accomplish). The only responsibility I see of a client is to disconnect peacefully.
So now the question..
Is there a good server side websocket library for .net that implements the latest web socket protocol? The client can use any client library that adheres to the protocol. What is the best practice to incorporate both web socket connections and a restful api?
ASP.NET supports WebSockets itself if you have IIS8 (only Windows 8/2012 and further). SignalR is just a polyfill,
If you do not have IIS8, you can use external WebSocket frameworks like mine: http://vtortola.github.io/WebSocketListener/
Cheers.
From the introduction on gRPC:
In gRPC a client application can directly call methods on a server application on a different machine as if it was a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a stub that provides exactly the same methods as the server.
The above paragraph talks about a client and a server, with the former being the one who is invoking methods to the other. What am I wondering is: can the server-end of the connection invoke methods that have been registered on the client?
No, a server cannot invoke calls on the client. gRPC works with HTTP, and HTTP has not had such semantics in the past.
There has been discussion as to various ways to achieve such a feature, but I'm unaware of any work having started or general agreement on a design. gRPC does support bidirectional streaming, which may get you some of what you need. With bidirectional streaming the client can respond to messages from server, but the client still calls the server and only one type of message can be sent for that call.
The protocol does not implement it, but you may pretend this situation.
Define a server method that returns a stream of a ServerRequest message:
import "google/protobuf/any.proto";
service FullDuplex {
rpc WaitRequests (google.protobuf.Any) returns (stream ServerRequest);
}
message ServerRequest {
float someValue = 1;
float anotherAnother = 1;
}
ServerRequest may be an Oneof, so your may receive different types of server requests.
If you need that your client sends back a response for each request, you may create a stream from your client to the server, but you will need to implement a logic in your server side that triggers a timeout waiting for that response.
service FullDuplex {
rpc WaitRequests (stream ClientResponse) returns (stream ServerRequest);
}
What you can do is start a HTTP server in both processes and use clients at each end to initiate communication. There's a bit of boilerplate involved and you have to design a simple handshaking protocol (one end registers with the other, advertising its listen address) but it's not too much work.
Why http based on request/response? Why server can't push data with http to client directly and must has to be response of client request? In start of connection I know that client has to send request but why after that client must continue request/response/req/resp. long polling, comet, Bosh and other server pushing method also based on req/resp method and not solve the question.
All your problems ok! RFC 6455 defines the WebSocket protocol. HTTP 1.1 supports bi-directional TCP-like sockets that do not require you follow the request/reply pattern. The original spec had only UTF-8 character coding support, but now with modern browsers, binary data can be sent down the wire as well. Working with WebSockets presents a new manner of framing a web application but it's growing browser support makes it a viable option for modern websites.
Node.js is the easiest way to get into using WebSocket's with the Socket.IO library. Do check it out.
Can anyone let me know how SignalR works internally in a high level way?
I am guessing it is flushing the data using Response.Flush and at client side it is sending Ajax requests at certain intervals. Is it correct?
No, SignalR is an abstraction over a connection. It gives you two programming models over that connection (hubs and persistent connections). SignalR has a concept of transports, each transport decides how data is sent/received and how it connects and disconnects.
SignalR has a few built in transports:
WebSockets
Server Sent Events
Forever Frame
Long polling
SignalR tries to choose the "best" connection supported by server and client (you can also force it to use a specific transport).
That's the high level. If you want to see how each transport is implemented, you can look at the source code.
There's also client code for each transport:
https://github.com/SignalR/SignalR/tree/master/src/Microsoft.AspNet.SignalR.Client.JS
If you're asking about how the long polling transport works in particular:
It sends an ajax request to the server that's waiting asynchronously for a signal to respond. When there is a signal or the request times out, it returns from the server and sends another request and the process continues. (I left some details out about how the client it keeps track of what it saw so it doesn't miss messages)
Hopefully that answers most of your question.
#davidfowl has already answered the major portion. However, to provide some more details regarding the difference in behavior of transports, specifically between WebSocket and other transports; below are some points.
WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket is supported only by IIS 8 or above, and the latest versions of Internet Explorer, Google Chrome and Mozilla Firefox.
While Server Sent Events, Forever Frame and Long polling, all three follow a one-way communication, and are supported by most of the browsers.