WCF server don't detect lost or broken connection?
-
BobJanova wrote:
Like all HTTP based web services, WCF doesn't really have the concept of a connection, so if you care, you need to do something like what you describe. Alternatively, you can just let the HTTP session expire if a user disappears.
sorry for not mentioning. This is a cybercafe software(netTcpBinding based persession scenario and server/client on the same lan).
BobJanova wrote:
If your service is doing something for which manual inspection of requests is necessary
by approval, I mean, client is sending me drink orders which opens up a form on server side and admin approves or cancels. This is where the story begins.If I don't approve in ten seconds(closetimeout=10) connection is broken. in order to avoid this, I create a backgroundworker for every session that listens incoming orders and handles the approval form, this way connection isn't dropped. But this time there are too many unnecessary backgroundworkers with extra load(think of 25+ clients/sessions) Also, same approval mechanism needed for clients for requests from server to clients and same load So, Do you have any better idea?
I expect that the baristas/bartenders should have their own client of the server, the Service code should not be asking them for input directly. The Customer (using Customer client app) connects to the Service and places an order (status pending). The Barista (using the Barista client app) connects to the Service for a list of pending requests. The Barista approves or declines the requests and prepares to fulfill the approved ones. The Customer's client connects to the Service and polls for updates to the requests and alerts the Customer. If there is a Manager who approves and declines the requests, then a third client app may be required.
-
BobJanova wrote:
Like all HTTP based web services, WCF doesn't really have the concept of a connection, so if you care, you need to do something like what you describe. Alternatively, you can just let the HTTP session expire if a user disappears.
sorry for not mentioning. This is a cybercafe software(netTcpBinding based persession scenario and server/client on the same lan).
BobJanova wrote:
If your service is doing something for which manual inspection of requests is necessary
by approval, I mean, client is sending me drink orders which opens up a form on server side and admin approves or cancels. This is where the story begins.If I don't approve in ten seconds(closetimeout=10) connection is broken. in order to avoid this, I create a backgroundworker for every session that listens incoming orders and handles the approval form, this way connection isn't dropped. But this time there are too many unnecessary backgroundworkers with extra load(think of 25+ clients/sessions) Also, same approval mechanism needed for clients for requests from server to clients and same load So, Do you have any better idea?
Ah, well, I don't have any experience of using the netTcpBinding, but I think the WCF framework is set up to operate over HTTP so it's possible it doesn't directly expose a disconnect event. If you want this kind of thing I'd personally recommend doing the TCP communication yourself to get full control, but I realise that's not for everyone. Does using WCF over TCP allow the server to make a call in a client (i.e. server push)? If so the best design looks to me to be: - client makes a request through the service, which pushes the request onto a queue for approval, and returns some sort of ID that the client can use to look this request up later. - client puts that ID in a local list of pending requests - server application has a thread (logically speaking, might not actually be a thread) which repeatedly takes the top item of the queue and presents it for an administrator to approve or decline. Note that this is not done in a service call. - when a queue item is processed (either confirm or deny), the server sends a message (in WCF terms, this means call a service method) to the relevant client stating the ID and whether it was approved - in that method the client triggers its further processing for that request The client UI can make it impossible to do anything much if there is already a pending request open, or it can allow multiple pending requests, depending on your requirements. But behind the scenes something queue based permitting any number of requests seems like the best approach.
-
BobJanova wrote:
Like all HTTP based web services, WCF doesn't really have the concept of a connection, so if you care, you need to do something like what you describe. Alternatively, you can just let the HTTP session expire if a user disappears.
sorry for not mentioning. This is a cybercafe software(netTcpBinding based persession scenario and server/client on the same lan).
BobJanova wrote:
If your service is doing something for which manual inspection of requests is necessary
by approval, I mean, client is sending me drink orders which opens up a form on server side and admin approves or cancels. This is where the story begins.If I don't approve in ten seconds(closetimeout=10) connection is broken. in order to avoid this, I create a backgroundworker for every session that listens incoming orders and handles the approval form, this way connection isn't dropped. But this time there are too many unnecessary backgroundworkers with extra load(think of 25+ clients/sessions) Also, same approval mechanism needed for clients for requests from server to clients and same load So, Do you have any better idea?
While I'm not 100% convinced that the architecture you're proposing is the optimal architecture for your particular problem, you can implement what you want using WCF Reliable Sessions[^]. Ignore the fact that it talks about SOAP - it also supports TCP, so it should fit with your model. Honestly, I would look for an alternative "occassionally connected" model such as MSMQ if I were you.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
I think you're making things hard on yourself. I don't see why the server would care about how frequently a client calls methods.
-
Hi, I have a working wcf server-client application.Client makes a call every 3 seconds.If client doesn't call any method for ten seconds, server drops the connection based on the closetimeout setting(10 secs).(not prefer but with this setting, if something happens to client like ethernet/power plug off, I detect lost connection) But as a side effect of this, if server's response time exceeds 10 secs(like a messagebox asking for a user confirm.), the client is waiting and the connection is gone of course, because client can't make another call until the previous one answered.(InstanceContextMode=PerSession) Oddly,it is said that setting a void method as "IsOneway=true" the client doesn't wait for server to finish process and so it can make another call. But it's not so in action, it still waits server to finish. ??? The question is: I want to get rid of closetimeout setting by setting it to int.maxvalue and detect lost connections by service or instance faults.Any way of doing this? (I tried the closed and faulted events of operationContext...etc with no success) (I didn't try faultContract because I don't want to send fault details to clients(am I wrong about this?). I only want whether the client is connected or not)
First to clear up some confusion. TCP, upon which netTcp is built has the following behavior. The only almost sure way to tell if the other end is still there is to send something to it. And then wait for a timeout/failure. And even that might not tell you (but probably will.) In a normal situation such a failure would occur quickly because the other end closed the connection. In abnormal situations the connection can be lost without a close. One way is to kick the power cord out of the wall. This is how TCP works. And there is no magical way to get around it. Some possible solutions. 1. The server closes the connection if it hasn't received anything for X seconds. The client must send soemthing, even a 'do nothing' every X/2 seconds to insure the connection remains alive. 2. Don't attempt to keep connections open. Open it, send, close. Do NOT be swayed by 'performance' issues around this. Those issues are related to high volume servers in data centers.
teknolog123 wrote:
if server's response time exceeds 10 secs
You need to DESIGN for failures. As an example what happens if the server gets bounced right then? Normal maintainance (or maybe not so normal) but not a catasphrophic failure but it isn't going to respond. So exactly what does that mean to your application. Maybe you could queue the 'ok' and if so then you should queue it right away regardless and then send it on a different thread.
-
PIEBALDconsult wrote:
I don't see why the server would care about how frequently a client calls methods.
If the client disappears without closing the connection then the connection will remain forever. Which won't work in a standard 24x7 type server.
There is no connection.
-
First to clear up some confusion. TCP, upon which netTcp is built has the following behavior. The only almost sure way to tell if the other end is still there is to send something to it. And then wait for a timeout/failure. And even that might not tell you (but probably will.) In a normal situation such a failure would occur quickly because the other end closed the connection. In abnormal situations the connection can be lost without a close. One way is to kick the power cord out of the wall. This is how TCP works. And there is no magical way to get around it. Some possible solutions. 1. The server closes the connection if it hasn't received anything for X seconds. The client must send soemthing, even a 'do nothing' every X/2 seconds to insure the connection remains alive. 2. Don't attempt to keep connections open. Open it, send, close. Do NOT be swayed by 'performance' issues around this. Those issues are related to high volume servers in data centers.
teknolog123 wrote:
if server's response time exceeds 10 secs
You need to DESIGN for failures. As an example what happens if the server gets bounced right then? Normal maintainance (or maybe not so normal) but not a catasphrophic failure but it isn't going to respond. So exactly what does that mean to your application. Maybe you could queue the 'ok' and if so then you should queue it right away regardless and then send it on a different thread.
jschell wrote:
You need to DESIGN for failures
Or design to avoid failure situations. By trying to use some sort of pesistent connection you add the possibility of a connection failure.
-
First to clear up some confusion. TCP, upon which netTcp is built has the following behavior. The only almost sure way to tell if the other end is still there is to send something to it. And then wait for a timeout/failure. And even that might not tell you (but probably will.) In a normal situation such a failure would occur quickly because the other end closed the connection. In abnormal situations the connection can be lost without a close. One way is to kick the power cord out of the wall. This is how TCP works. And there is no magical way to get around it. Some possible solutions. 1. The server closes the connection if it hasn't received anything for X seconds. The client must send soemthing, even a 'do nothing' every X/2 seconds to insure the connection remains alive. 2. Don't attempt to keep connections open. Open it, send, close. Do NOT be swayed by 'performance' issues around this. Those issues are related to high volume servers in data centers.
teknolog123 wrote:
if server's response time exceeds 10 secs
You need to DESIGN for failures. As an example what happens if the server gets bounced right then? Normal maintainance (or maybe not so normal) but not a catasphrophic failure but it isn't going to respond. So exactly what does that mean to your application. Maybe you could queue the 'ok' and if so then you should queue it right away regardless and then send it on a different thread.
jschell wrote:
This is how TCP works. And there is no magical way to get around it.
you really cleared the confusion with this info. Thanks
-
There is no connection.
-
jschell wrote:
You need to DESIGN for failures
Or design to avoid failure situations. By trying to use some sort of pesistent connection you add the possibility of a connection failure.
PIEBALDconsult wrote:
Or design to avoid failure situations.
One can certainly ignore failure scenarios. But other than that it isn't possible to create a multi-server dependent system and not have failure situations.
PIEBALDconsult wrote:
By trying to use some sort of pesistent connection you add the possibility of a connection failure.
Yes but... For connectivity within a data center that is low. For high volume within a data center connectivity might make a performance difference. Failure scenarios due to lost connectivity exist even with non-persistent connections.