|
Please ask this in the Regular Expressions forum instead. We're trying to get the traffic up there. Forum[^]
|
|
|
|
|
Hi one hi all!
Using the example from , http://www.undisciplinedbytes.com/2010/06/html-5-c-web-sockets-server-and-asp-net-client-implementation/[^]
I have managed to add basic webSocket support to me TCP server engine. As I have very little knowledge in html and interested only on the sever side I came across few questions regarding the implementation of the WebSockets server:
1)Does the buffer of the handshake arriving from the client, always arrives in one chunk?
2)If not, how can I tell when I have all the handshake message?
3)I have change ‘ws’ to ‘wss’ (both in client and server) in order to use the secure option. As
a result the handshake from the client arrives (what seems to be) encrypted, how can
encrypt it? Where is the key?
Thank you all
|
|
|
|
|
I want to create a web service for a chat application which will instead of Request/response model use push model.
Client app will be notified of a new message, user logged in etc.. by the web service.
Does anyone have know where to start any good article with basic knowledge for creating such push web services.
|
|
|
|
|
I certainly don't; push is evil and never works.
My chat system uses pull. I still haven't yet converted it to use a Web Service.
One of the benefits of using pull is that it makes it easier to allow the client to poll at intervals of the user's choosing and to have a "check now" kind of button.
|
|
|
|
|
Agree to this poll model which is good but now a days client apps needs to be light and with growing numbers of client medium [mobiles, tables etc..] it is much better to let the server push the messages and client to listen. Something similar to push notification of Apple.
Do you have any articles on push web service?
|
|
|
|
|
nitin_ion wrote: it is much better to let the server push the messages and client to listen
No it's not. Trust me on this - I spent a lot of time working on a push application back in the late 90s, and the problems that had to be overcome are immense. With a push mechanism, you have to keep track of connected clients and track of what you have sent to the client. Suppose that you get a temporary network outage to a client and you push a message out, you need to track this and take some action based on this - for instance, you may allow a retry interval and then attempt to push the message again.
Remember that connections are finite resources, so you'd have to create a disconnected push mechanism which is a whole magnitude of complexity beyond. There are all sorts of tricks that you have to employ there.
|
|
|
|
|
Yes for most of the issue pull is better but there are some areas where push is better. like ads, alerts etc.
|
|
|
|
|
If you look at ad services (such as the one's here on CP), you'll find that the majority are based around pull mechanisms. Similarly, alerts are generally polled on web based systems.
|
|
|
|
|
There is nothing good about the push model, period.
Users will despise you, and waste tons of money on tech support to remove your nasty, intrusive application from their machines. People will revile you, and spit on your avatar in FarmTown, even at the expense of having to wipe their screens once in a while with a damp cloth. You will be a pariah in the realm of software development, and will never be invited to the really good hospitality suites hosted by top vendors at developer conferences, the ones where the booze and food are free, and served by scantily clad booth bimbos they rent by the hour from the local brothels. I, for one, refuse to buy any Adobe product because of their constant update notifications for their ubiquitous Reader product, and I despise Microsoft for their intrusive approach to installing inadequately tested patches that destroy perfectly functional machines, overnight. A pox on whoever conceived the notion of push products; may the fleas of a thousand camels infest his armpits, and may all the crabs in Las Vegas take up residence in his crotch.
Just don't...
Will Rogers never met me.
|
|
|
|
|
Web services are inherently request/response. If you really need push you should setup two way communications between your client and server or bring up web services on your clients and send from your server (reversing the process).
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
It can't be done; as Mehdi says, web services are implemented on top of HTTP and are inherently request/response (i.e. pull) oriented.
Either you can do it with polling (some sort of intelligent polling that alters its frequency based on activity, if you want to be friendly to your server), or you can come away from the web service idea altogether and create a client/server connection based (probably TCP) chat application. There is simply no such thing as a push model web service due to the protocol on which web services are defined.
However, on any thin client (whether in browser or not) to a web service, you are sending quite a lot of requests anyway, onto which you can piggyback update notification information without adding extra server load. For example, imagining an online IRC type application, you are sending a request every time you type a message, change your status, look up information on another user, join or leave a room, as well as obvious things like following links. The trick is to include update notification (for chat messages, PMs, users in a room, etc) as part of every service response, if you want to minimise requests and still get frequent updates.
|
|
|
|
|
ok, but then how does push notification services work. aren't they web services?
|
|
|
|
|
|
can callback functions be used to see if a user sends message using request/response to webservice then web service should push that message to that user. something which is google doing
if we see in other messengers they do it using traditionally req/res but google , skype are using push for their messages.
|
|
|
|
|
Skype opens and maintains a persistent TCP connection to a server.
Google: I guess you are talking about the standalone app? The in-browser chat uses AJAX and polling. I think their standalone app opens a persistent TCP connection but it might be using client side polling, I'm not sure.
I don't really understand your first sentence in this post. You can use a callback to see when a particular request to the service returns, if you fire the request asynchronously. Is that what you mean? (Synchronous WCF client calls actually wrap this asynchronous approach and use a wait handle to wait for a response, if I remember right.) That doesn't change what is going on underneath or the fact that a request must be initiated by the client, though.
|
|
|
|
|
nitin_ion wrote: how does push notification services work
They don't, they never have, it's a very bad idea.
Just implement pull and allow the user to determine the frequency he likes.
|
|
|
|
|
like you said polling there is also other mechanism like using comet with wcf and using callbacks.
do you have any articles on polling, comet or callbacks which gives knowledge on how to use it in wcf
|
|
|
|
|
Polling is trivial (a client side timer or other mechanism that repeatedly makes a request to the service asking about updates).
The comet method I haven't heard of before, but it seems to be an abuse of the TCP timeout mechanism whereby you stall a request until there is an update. I'm not sure there is a way to do that with a WCF service without going in at the low level. This form of polling is bad though (for the reason that persistent connections are: while that request is open, it counts against your machine socket resources, concurrent connections etc which are generally more precious than bandwidth), except for very specific cases where you know there will be an update soon (within a second or so).
You can use callbacks in a WCF client to respond to a service request asynchronously (i.e. you fire it off, continue processing and respond to the request you initiated later). This would typically be used as part of polling, as you don't want to stall client interaction while you want for a response.
Honestly, for a chat application, you are better off either using persistent connections (think IRC) for an update-critical standalone app, or using simple HTTP with client side polling (either through AJAX or thick client code doing a similar thing) for a less update-critical one or a web (in browser) chat. This is not what web services are for and they will get in the way rather than helping you.
|
|
|
|
|
nitin_ion wrote: do you have any articles on polling, comet or callbacks which gives knowledge on
how to use it in wcf
You have already been given an answer to this. Your post here is just plain rude.
|
|
|
|
|
|
Web services don't technically push. They're based on a request/serve paradigm, meaning you have to connect, call a method, and accept the output.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Thanks, this is correct. I just looked at some articles and accordingly if we use basichttpbinding we cannot create duplex service but with wshttpbinding we can.
but with it then we need to make sure that ports, firewall issues are taken care of on client machine.
I am not sure but there should be some way using using basichttpbinding by which i can create callback methods.
|
|
|
|
|
You obviously don't have even the most rudimentary understanding of the mechanics of a web service. Once more, a web service is a request/response system, and nothing more. If you want to "push" data somewhere, you cannot do it with a *web* service.
If you want to push data without it being requested, your best bet is to use a *windows* service that listens for connections, and broadcasts the data (via WCF or some other transport mechanism) to any client that might be listening and that knows how to interpret and react to the data being pushed.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
You could always have a little node.js server up and running, and when various client actions occur (log on, etc), it sends a message to your node.js server, which would then broadcast another (push) message. And then the client "listener" js file on your front end could handle the pushed message in whatever way you see fit. And basically any active client node would accept the message/action.
________
John Y.
Developer
|
|
|
|
|
Hi,
If possible Please explain me DI with very simple example.
Even share me if u have any ppt for the same.....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
