1

I have a synchronous legacy WCF service with a potentially long running operation. For some clients, this operation seems to cause network timeouts - not at the client or service end, but somewhere in the middle at some proxy server in a network topology that is opaque to me.

The question is: Could I solve this problem by using the event based asynchronous pattern on the service side (using IAsyncResult / BeginXXX(), EndXXX())?

I am puzzled about how the callback mechanism of async services actually works on the network level. Does the client do periodic polling, or some kind of long polling, or something completely different? Unless I am simply bad at using Google (I believe I am not), the MSDN documentation seems to be completely lacking in that respect. In only keeps going on about how async programming helps you to build responsive GUIs and whatnot.

The question is: Will it prevent proxies from timing out requests that they believe to be taking too long?

EDIT: To clarify: The service in question uses basicHttpBinding.

chris
  • 2,541
  • 1
  • 23
  • 40

3 Answers3

2

There are no callbacks at the network level. Async IO is all about not blocking threads on a single machine. Both communication parties can independently decide to use sync or async IO as they please. Neither party can even detect what the other chose.

You are using the SOAP-based basicHttpBinding. SOAP has no notion of asynchronous invocation. Neither does any of the other bindings.

Async IO can do nothing to resolve your timeout problem. Those timeouts are caused by something on the network (as you said). The network has nothing to do with how a service is implemented. It cannot even find out and respond to it.

Community
  • 1
  • 1
usr
  • 168,620
  • 35
  • 240
  • 369
  • So you are saying that on the network level, a synchronous and an asynchronous web service call are the same thing? – chris Aug 14 '14 at 11:22
  • @chris yes. You couldn't detect the difference using WireShark or Fiddler. This is the same with sockets. You would expect the same to be true for sockets, right? The remote side doesn't care whether you call Send or BeginSend. The bytes sent are the same. – usr Aug 14 '14 at 11:22
  • Well, that wasn't the answer I was hoping for, but at least now I have the confirmation that I need a different solution ... – chris Aug 14 '14 at 11:25
  • @chris I suggest you ask a new question to find out what could be causing those timeouts. Maybe some proxy cuts idle TCP connections?! Because as I said: During a long-running call the connection is 100% idle. – usr Aug 14 '14 at 11:28
  • Yes, some proxy cutting idle connections is that is exactly what I believe to be the culprit. Unfortunately I don't have control over the network topology where the problem happens, so I will probably have to try to refactor the service to avoid long-running calls. – chris Aug 14 '14 at 11:32
1

The timeout things are at the http stack, and have nothing to do with the async things in programming. Google "windows http stack" you may find out why.

"In only keeps going on about how async programming helps you to build responsive GUIs and whatnot." this helps you not to block the UI thread with a long running operation like a http request/response.

A WCF service is by default multi-threading -- upon one request, a new thread is created.

On the client side if you are using .NET 4.5, you may find the client proxy classes generated support async operations, however, this has nothing to do with http timeout. These functions make asynchronous/parallel programming easier on the client side.

In short, the timeout is determined by the http stacks on both server and client. If you have controls over both server and client, you may increase timeout values on both side, as quick and dirty solution.

ZZZ
  • 2,752
  • 2
  • 25
  • 37
  • I know this happens at the HTTP stack, and like I said, it probably happens neither at the service or the client, but at some proxy in the middle. So increasing timeouts at server and / or client won't help. I think the question really boils down to how the callback mechanism works on the network level - does it keep a connection open all the time, does it do some kind of polling, ...? – chris Aug 14 '14 at 11:16
  • Ok, got it now. Looks like I misunderstood what async services are meant to do. – chris Aug 14 '14 at 11:27
  • If you have a long running operation on the server side, say lasting over 2 minutes or even a few hours to generate a result, it is not practical to have the client to waiting for the result and keep a connection. Then you may design an asynchronous protocol at application level. For example, the service will delegate the long operation to another service not subject to timeout, and deliver the result to a virtual mailbox, to which the client may query regularly. – ZZZ Aug 14 '14 at 12:31
  • Yes, I know - my misunderstanding was to assume that an async service method does just that. – chris Aug 14 '14 at 12:33
1

I don't think it prevent the timeout as the asynchronous development is on the client side independent of the protocol and the network configuration. For HTTP this is likely a registry setting.

My understanding is that windows I/O is by nature asynchronous so I don't think there will be any polling, rather once the IO is complete some sort OS level interrupt will occur. You may find this article by Stephen Cleary helpful. Also the books Windows Internals might be a good reference as well.

NeddySpaghetti
  • 13,187
  • 5
  • 32
  • 61