I am new to SignalR and I try to understand the difference between consistent connection and long polling,Is there different use in methods ? is one better than the other? are there any diffrenet functions need to polling and other functions to use consistent connection?, I googled but didn't find a simple answer to this question, can someone help? need an explanation.
SignalR is a framework that allows us to build real-time web applications. Ideally, we would use web sockets for this. However, web sockets is a new protocol and requires support from both the browser and the server. Thus, web sockets are not generally available and SignalR tries to provide an abstract connection similar to web sockets but built upon existing technologies and techniques. This abstraction is called a Persistent Connection.
Persistent connection is the term used to describe SignalR's abstract connections.
Long polling is one of several techniques used to implement SignalR's persistent connections (the others are Forever Frame, Server-Sent Events and Web Sockets).
Related
It's seems to me that SignalR is only temporary step towards global domination of System.Web.WebSocket, and it's lower level System.Net.WebSocket.
If I have IIS8, and my clients have IE10, do I have any reason to use signalR?
Does it have a future?
(Of course, the same goes for Socket.IO + Node.js)
Thanks
ref:
http://pieterderycke.wordpress.com/2012/07/20/websockets-vs-signalr-or-why-you-should-not-have-to-care/
A number of advantages:
SignalR abstracts the actual connection type away so that you only deal with a logical connection. The advantage is that you can switch to other connection types if you want to without having to change your code (SSE might actually provide better performance than WebSockets in some cases).
You get the fallback options (long-polling etc.) for free in case you need to connect from a client that doesn't support WebSockets.
Hubs provide a level of organization (you can do that yourself, of course, but it's a good starting point, and it's convenient)
SignalR provides a rich API for calling a specific client, a group of clients, all clients (including the ability to exclude certain clients). Again, you can implement it yourself, so this is mostly about convenience.
You can pass strongly typed parameters between client and server (both ways).
You'll (probably) have to deal with less boilerplate code with SignalR.
Scale-out support
Off the top of my head, the group membership/broadcast and the ability to scale out on a webfarm are features that you don't get built into the WebSockets classes - so if you're using those features, you'll probably continue to use SignalR for the near future.
Additional to Damien's points:
SignalR also supports long polling and some other techniques if the user has no browser with web socket support
It's very easy to call methods on the client from the server
Also, when WebSockets is updated, SignalR will also be updated, so you won't need to worry about coding for the new version of WebSockets.
I am using the SignalR silverlight client and my hubs are hosted in the windows services. Hubs talk to the compact database to return the data.
What i have noticed is, the time taken to return the data is alarmingly high even though the volume of data returned is not significant and also since the hubs server is local, do not see any network latency issues as well.
I want to know, what are the performance improvements/configurations that can be done at the SignalR hub level in order to improve the performance?
eg:
Is there any standard Transport channel that I should use depending on the client type?
Are there any configuration parameters that i should set?
Thanks,
Alpee
As far as I understand, SignalR uses fallback protocols so it would depend on the capabilities of your server and client.
You might want to take a look to this for further abstract
Moreover, there are some performance recommendations (only related to IIS and SignalR together) in the main project wiki
I would recommend you to use Performance Counters (check "Generating Client Load with crank" section) to better diagnose where is your performance issue.
Hope that helps,
Cheers
The short story: me and friend are making a multiplayer action game and we thought playn would be great for this. Android, java and HTML5 support is the most important ones but we don't want to cut out the others if not necessary.
The problem is now when we want to implement the networking part of it. We have implemented our own capable server and thought we would use long polling http requests for communication. We estimate now we need some way to have one thread running for the communication that use messages and two multithread safe queues. One queue for incoming messages that the update() part can consume from and one queue for outgoing messages to the server.
Is there any way to implement this without losing platform support? Or any other idea how we can implement this?
PlayN currently has no cross-platform support for persistent socket connections to a server. You will need to implement your own cross-platform abstraction. You can use WebSockets for the HTML5 backend, and you can look for a WebSockets library for Android and whatever other platforms you intend to support.
You can also use the Nexus library, which is designed to work with PlayN and provide client/server communication. However, it raises the level of abstraction substantially beyond passing simple messages between the client and server, so it might be easier to just implement your own simple WebSockets based communication than to learn how Nexus works.
Hey,
first of all this is a conceptional question and I do not know if StackOverflow is the appropriate place - so my apologies if I am wrong.
Nowadays the web is not only used for passing raw informations. Many and especially complex web applications are in use. These web application seem to be so complex that it seems irrational to use the HTTP protocol, which is based on so simple data exchange, plus it is stateless.
Would it not be more convincing to use remote invocations for this web applications? The big advantage to my mind is a unified GUI by using HTML. But there are applications, which have no need for a graphical interfaces and then it comes to a point where the HTTP protocol is really cumbersome.
Short answer: HTTP is allowed through firewalls where other protocols would be blocked.
A short partial answer is: first, for historical reasons - HTTP was used since the dawn of the web as protocol for requesting documents, and has since been used for some different purposes. One reason to keep using it is that it is generally served on port 80 which you can be sure won't be blocked by firewalls between your client and the server. The statelessness of the protocol may not always be what you want, but it has at least the advantage of protecting the server side from very trivial overloading problems.
OS independence
firewall passing
the web server is already a well understood and mostly "solved" problem in terms of load balancing, server fall over, etc.
don't have to reinvent the wheel
Other protocols are being used more and more now, including remote invocations and (the one I am particularly familiar with) WCF (which allows binary TCP/IP data transfer).
This allows data to travel faster for applications which require more bandwidth. For example an n-tier application may use WCF binary transfer between application and presentation tiers. Also public web services allow multiple protocols, including binary.
For data transfer protocols, firewalls should be configured (ie. expose a port specifically for your application), not worked around, I would not recommend using a protocol because firewalls do not block it.
The protocol used really depends on who will consume it and what control you have over the consumption - eg external third parties may need a plain-text version with a commonly agrreed data interface. On the other hand, two tiers in a single web application may be able to utilise binary data transfer for performance and security.
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck