I was intrigued by this post from Tomek which has links to a prototype of an application built with Silverlight but using WebSockets.It’s kind of interesting because running the application in IE9 gives me; 
because Chrome has support for WebSockets already and so the sample switches out the Silverlight functionality. If you’ve not read about WebSockets then there’s a starter here and info on the protocol up here.If you’ve programmed with connected, TCP sockets then you know that the model is essentially;Server listens. Client connects.
Connection stays open during lifetime of communication.
Client and Server send stuff any time they like in a full-duplex manner.
So, traditional sockets are great in that they allow full duplex comms such as when the server wants to notify the client that something has happened but they’re not so great in that they require an open connection which tends to limit your server side scalability. They’re also not so great when it comes to crossing boundaries that only allow HTTP on port 80 or 443. If you’ve programmed with HTTP then you know that the model is essentially;Server listens. Client connects.
Client sends request.
Server sends response.
Client (generally) disconnects as soon as that response comes back.
and so HTTP is a great use of sockets in that it makes the model a lot more scalable by not requiring a permanent connection between the client and the server and server-side state but, because of that lack of connection, you can’t have the server notify the client of something because, generally, the client and server have no connection at any particular point in time. Now, of course you can use HTTP in various ways to try and give the illusion that the server does have a connection to the client and that’s normally done by just having the client poll the server on some period essentially asking “Do you have anything for me right now?” with the expectation that the answer from the server will frequently be “no”. So, a server wanting to “notify” a client simply has to put its notification data into a database and wait for the next time that client polls when it will be able to deliver the notification.
Read more: Mike Taulty's Blog
because Chrome has support for WebSockets already and so the sample switches out the Silverlight functionality. If you’ve not read about WebSockets then there’s a starter here and info on the protocol up here.If you’ve programmed with connected, TCP sockets then you know that the model is essentially;Server listens. Client connects.
Connection stays open during lifetime of communication.
Client and Server send stuff any time they like in a full-duplex manner.
So, traditional sockets are great in that they allow full duplex comms such as when the server wants to notify the client that something has happened but they’re not so great in that they require an open connection which tends to limit your server side scalability. They’re also not so great when it comes to crossing boundaries that only allow HTTP on port 80 or 443. If you’ve programmed with HTTP then you know that the model is essentially;Server listens. Client connects.
Client sends request.
Server sends response.
Client (generally) disconnects as soon as that response comes back.
and so HTTP is a great use of sockets in that it makes the model a lot more scalable by not requiring a permanent connection between the client and the server and server-side state but, because of that lack of connection, you can’t have the server notify the client of something because, generally, the client and server have no connection at any particular point in time. Now, of course you can use HTTP in various ways to try and give the illusion that the server does have a connection to the client and that’s normally done by just having the client poll the server on some period essentially asking “Do you have anything for me right now?” with the expectation that the answer from the server will frequently be “no”. So, a server wanting to “notify” a client simply has to put its notification data into a database and wait for the next time that client polls when it will be able to deliver the notification.
Read more: Mike Taulty's Blog
Posts
0 comments:
Post a Comment