WCF server don't detect lost or broken connection?
-
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)
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. The considerations you need to make are similar to when creating a normal web application. Requiring a login to make an authenticated session in the first place means that it generally doesn't matter if you have inactive sessions not being actively closed, as they are pretty difficult to hijack (I think IIS sessions are bound to IP and session ID). A web service call should never block waiting for server side user input. Web services should be able to run in a lights-out environment, with the only communication needed to talk to them being the service interface itself. (Any client side user input can be taken before or after particular service calls, which may require splitting a large call up into smaller ones if intermediate input is required, but each call should be self contained and executable.) If you want to provide information at runtime so you don't have to recompile the service, you should use some sort of configuration file or data store which the service can look at to make its decision. If your service is doing something for which manual inspection of requests is necessary (this is very rarely actually necessary, but perhaps for military or dangerous research environments there are times when it could be), the service function should place a request onto a queue, and immediately return with a value that indicates that the request is pending approval. Any further attempts to do anything on that request that can't proceed until the server-side operator approves it should cause service methods to throw exceptions until it is manually approved, and the client should poll to find out whether the status of any of its pending requests has changed. That queue should also be read by another application which is what the manual approver will use to inspect pending requests. I strongly suspect you don't actually need that but if you think you do, please state your requirement for that in more detail so some better help can be created for you (if that one paragraph version was not enough).
-
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. The considerations you need to make are similar to when creating a normal web application. Requiring a login to make an authenticated session in the first place means that it generally doesn't matter if you have inactive sessions not being actively closed, as they are pretty difficult to hijack (I think IIS sessions are bound to IP and session ID). A web service call should never block waiting for server side user input. Web services should be able to run in a lights-out environment, with the only communication needed to talk to them being the service interface itself. (Any client side user input can be taken before or after particular service calls, which may require splitting a large call up into smaller ones if intermediate input is required, but each call should be self contained and executable.) If you want to provide information at runtime so you don't have to recompile the service, you should use some sort of configuration file or data store which the service can look at to make its decision. If your service is doing something for which manual inspection of requests is necessary (this is very rarely actually necessary, but perhaps for military or dangerous research environments there are times when it could be), the service function should place a request onto a queue, and immediately return with a value that indicates that the request is pending approval. Any further attempts to do anything on that request that can't proceed until the server-side operator approves it should cause service methods to throw exceptions until it is manually approved, and the client should poll to find out whether the status of any of its pending requests has changed. That queue should also be read by another application which is what the manual approver will use to inspect pending requests. I strongly suspect you don't actually need that but if you think you do, please state your requirement for that in more detail so some better help can be created for you (if that one paragraph version was not enough).
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?
-
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.