".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
I want to understand the concept of the Join method.
When I use Thread1.Join() does it mean that Thread1 and the main thread runs simultaneously?
If not, I would be happy if you suggest me other method to do it
Thread.Join has nothing to do with making multiple threads run together - you can think of it as a mechanism where a parent thread can join to child threads and wait until they are finished. It blocks the calling thread and waits for the other threads to finish before it continues processing.
So, why would you want to do this? Well, if your parent thread completes processing faster than it's child threads then there would be trouble if the parent thread terminated leaving the child threads running, if those child threads had to access something on the parent thread.
There is no mechanism for guaranteeing that two threads will run simultaneously - the OS is responsible for allocating threads, your application must respect the rules given to it. Plus, of course, you can only have two or more threads running together if you've got a multi-core machine.
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?
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.
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.
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.
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.
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.