There is a c# project, hosting several wcf services,including basichttpbinding and nettcpbinding.
And a silverlight project, consuming the services. For the nettcpbinding part, it establishes a connection with the server. When the server gets new data elsewhere, it send the data to the clients connected ,via callback channel.
About silverlight, I know nothing but it runs at the client. I think this is the important thing: since sliverlight runs at the client and is written in c#, it's easy to consume wcf services, including duplex ones.
My task is to rewrite the silverlight project, mainly using javascript.
For the non-duplex part, I wrote several ashx handlers, and invoke it with ajax. (Is that right?)
But for the duplex part, after reading some posts I found polling seems the only way. When the server receive new data, it stores it somewhere, and the client invoke a handler every several seconds, the handler then returns the new data. So the server can't send the data to the client actively.
Am I doing it rightly, or any other ways?
Web sockets is the new HTML5 standard that supports push from server to client. (Actually web sockets are probably superior to the Silverlight duplex classes, which don't use true push under the hood but rather old-fashioned long polling with periodic "keep-alive" signals from the client.)
I'd suggest taking a look at SignalR, which is an ASP.Net component that wraps web socket functionality, and also "falls back to other compatible techniques for older browsers".
I was in a similar position a couple years ago: I had a Silverlight client talking to a duplex WCF server that I needed to port to JavaScript/HTML5. The question was, "What do we do about the backend?" I settled on exactly the same scenario that #McGarnagle describes, namely, switching to SignalR on the backend, and using the SignalR JavaScript client to communicate to that backend. I could have spent a great deal of time rearchitecting the WCF backend to share logic with SignalR, but because we were effectively abandoning our Silverlight client, it ended up making more sense just cutting and pasting the code powering the WCF service into the new SignalR hubs.
About the only thing I didn't like with SignalR (at the time) is that it only used dynamic objects to communicate to the client. I preferred (and continue to prefer) static, compile-time checking. I think there are ways to do that now with SignalR and TypeScript, but I haven't investigated them recently.
The primary alternative, by the way, that I investigated was using JavaScript to talk to the same WCF service. While there were supposedly some ways to get that to work, it didn't seem like they were very mature and were unlikely to be well supported going forward. SignalR is definitely the approach you'll want to use if you're trying to use C# on the backend and JavaScript on the client and need two-way communication: steer well clear of WCF in that scenario.
Related
I have become very comfortable with PHP and mySQL over the past couple months, but I have recently wanted to create a game (with database connections) that needs even better responsiveness then AJAX. This is where I came across sockets. I do not want to branch into Node.js (I am more comfortable with PHP servers) but PHP sockets can't be pushed information via JavaScript, which is crucial for responsive user input.
In short, I am seeking a method with the responsiveness of sockets but that can be pushed by the client in JS and received in PHP on server, similar to AJAX but bidirectional and fast.
Note I may be misunderstanding some of these concepts as a new member to this crazy new set of servers. Just correct and direct me please.
To build a PHP websocket server, Take a look at RatchetPHP: http://socketo.me/
It uses a sub protocol, WAMP so your websocket connection will have channels (topics).
Cons: It still uses the version 1 of WAMP subprotocol, the author suggest to use Thruway.
But RatchetPHP is better documented, and let you learn to implement websockets easily.
So currently, I am working on migrate an old project that implemented WCF service and consume it through Silverlight client. This WCF service is using duplex polling method that Silverlight automatically understands and knows how to deal with it. Hence, a new HTML client will be replacing that Silverlight client.
After doing some research, I found some working solutions: using long polling web api or similar, adding support for WebSocket in the WCF through .NET WebSocket implementation, and using SignalR. So far, I am leaning more to SignalR due to the fact that I want to minimize the changes to the WCF as much as possible.
So if my understanding is correct, when using SignalR, it will create a Hub proxy that communicates between the service in the server and the client. Also, it will take care of the transport for the communication, in which it can use WebSocket by default and fall back to other protocols if WebSocket is not supported in the browser, and it can do so without the implementation of the protocol in the service.
My question is that if I want to use SignalR with my current WCF service, what would be the steps to make it work? The WCF service is a self-host that is running as Windows service on a server. Inside the WCF service, I have different end points for sub-services as well as the current end point to the Silverlight client. So far I was be able to add self host SignalR with the WCF service project and it is running, but I am not sure what would be the next step. Do I have to add a separate end point for the SignalR hub?
Another question is that do I need to make some modification to the duplex services to make it work with SignalR? Also, can the client project be separated from the SignalR within the WCF service project? And finally, compare between adding support for WebSocket within the WCF service and just implement SignalR, which one would have a better advantage in long term.
Thanks.
.Net 4.5 has introduced NetHttpbinding in WCF that uses websockets automatically for duplex message pattern and http for request reply message pattern.
More on Nethttpbinding here -
https://msdn.microsoft.com/en-us/library/hh674273(v=vs.110).aspx
I put together an AJAX chat a while back ASP.NET MVC and jQuery. The javascript would hit the server about every 7 seconds to check for new messages. Obviously this was horrible on performance as the chat grew and included more and more users. The site traffic grew exponentially with so many requests going on. A user could leave the computer on all day and not even be there and they would still be making hits every 7 seconds.
Is there a better way to do this? I have heard of something called "push" but I haven't really been able to wrap my head around it. I think I just need pointed in the right direction.
1.) What is the best way to develop an AJAX chat and have it be scalable?
2.) What is push and how would I just that with jQuery?
1.) What is the best way to develop an AJAX chat and have it be scalable?
I agree with #freakish about the complexity and potential lack of scaling of IIS.
However, there is a relatively new Microsoft option in the works called SignalR which could become a core part of ASP.NET. More details in this related SO Question:
AJAX Comet - Is there any solution Microsoft is working on or supports to allow it to be scalable?
2.) What is push and how would I just that with jQuery?
Partially answered elsewhere, but it's a long-held persistent connection between the server and the client which means the server can instantly 'push' data to the client when it has new data available.
jQuery does support making AJAX requests but the core library doesn't support expose ways of doing HTTP Long-Polling or HTTP Streaming. More information in this SO answer to 'Long Polling/HTTP Streaming General Questions'.
Server push is a technology that allows the server to push data back to the client without forcing client to make many requests (like every 7 seconds). It is not really a matter of javascript but rather good server scripting. The upcoming HTML5 will make it simple due to server-sent events and/or WebSockets. This will be a true TCP connection between different machines.
But if you intend to make a webpage compatible with older browsers, then the most common technique is the long polling. The client sends request to the server and the server does not respond to it until it has new data. If it does then the response is made and the client immediatly after receiving data calls the server with new request. In practice however this requires the server to be well-written (for example it has to maintain thousands of idle requests at the same time) and can become a rather big challenge for developers.
I hope this helps. :) Good luck!
The technique you should use is the real-time persistent long running connections over a web page using WebSockets. You can use this library.
Node.js is becoming quite popular to build something like this and supports socket connections so you could push the data out only when there is a new message. But that would be learning something completely new.
Another nice potential would be to use MVC's OutputCacheAttribute and use the SQL dependency option so your AJAX page could be cached and would only be a new request when a new chat message appears. Also you would want your controller to be an Asynchronous controller to help reduce the load on IIS.
Enjoy, optimization is always fun and very time consuming!
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.
I have to program websites, but I rather don't like the static HTML nature. I prefer more of a client-server architecture.
Now I've figured, that with XMLhttp, you can basically dynamically update your page and send/request for information/action to/from a server. So this would basically cover the client area.
But to complete a client-server architecture, it is necessary for the server to send/request information, too, without being queried.
Is there any way, for example for a chat server, to send back a received message to all clients (the clients use a web browser) without that the clients have to query in a fixed interval? I want to implement that one can see while you type something in.
There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.
1. Polling
Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.
This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.
2. Long Polling
When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.
The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.
3. COMET
COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.
Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.
4. RIA
Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.
You can find tutorials on the internet for each of these options.
5. Web Sockets
If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.
I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.
I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.
This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
Special Mention
If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.
Conclusion
The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.
Yes, you can use COMET.
The client has to tell the server when the client-user begins typing. You've got a couple options here.
Frequent requests from the server for the latest activity. This would be taking place for each user involved in the chat. The same request could be used to send user-specific activity to the server as well: "Jonathan is typing..."
Long-polling. This essentially requests information from the server, and the server keeps the connection opened until it has something to send back. So your requests are minimized, but your connections stay opened longer.
Depending on your traffic, type of data being transmitted, server-environment, and many other factors, one of these options may shine more than the other.
You can use Silverlight for push notifications. Look at PollingDuplexHttpBinding. Since you are using ASP.Net MVC, adding Silverlight will be easy.
Look at this page for more information.
Based upon the REST architecture the html system is based upon, the servers role is to simply act as a resource for the client to pull from. I am generalizing but there are tools to implement this type of action on the client side, rather than on the server side.
You are better off writing/using a library that can request updates from the server periodically. You can encapsulate these types of requests in a javascript object that can fire events. This way your client side script can act like it's getting notified from the server. Review some common stuff with COMET you can probably find some tools to help you client side code.
HTML 5 has some tentative attempts at this type of functionality, but if you want your app to work on older browsers, your better off using more stable methods, like AJAX requested updates.