6

In the client side every time I call a function from my WCF service, it waits until the function is complete at the WCF Service, like calling a local function. So I added an extra function for each one that starts the intended function in a new thread, so that almost all my function are like this:

EX:
I call a function from CLIENT side client.ReceiveFile() :

private void SendFile(Socket socket, Job job, DoWorkEventArgs e)
    {
        UpdateInfo(job.Name, job.Icon, job.Size);
        client.ReceiveFile((_File)job.Argument, bufferSize);
        SizeAll = job.Size;
        UpdateCurrFile(((_File)job.Argument).Path, "1");
        SendX(socket, ((_File)job.Argument).Path, e);
    }

In the the server I have to do it this way:

 public void ReceiveFile(_File file, int bufferSize)
    {
        System.Threading.Thread th = new System.Threading.Thread(unused => ReceiveFileTh(client, file.Name, file.Size, bufferSize));
        th.Start();
    }
    private void ReceiveFileTh(Socket client, string destPath, long size, int bufferSize)
    {
        try
        {
            ReceiveX(client, destPath, size, bufferSize);
        }
        finally
        {
            CloseClient();
        }
    }

The point is, when I sendFile from client, it tells the service to start receiving, but if I didn't start a new thread, the client will wait for the service to receive the file, and will not send the file data.

So does WCF support a way that doesn't make the client wait for the service function to be done! or I will have to use the above method?

McGarnagle
  • 101,349
  • 31
  • 229
  • 260
Murhaf Sousli
  • 12,622
  • 20
  • 119
  • 185

2 Answers2

15

what you're looking for is [OperationContract(IsOneWay = true)] for more details see http://msdn.microsoft.com/en-us/magazine/cc163537.aspx

nathan gonzalez
  • 11,817
  • 4
  • 41
  • 57
  • 2
    Yes. That's true. By default this param is false, so client will be waiting while function executes. When it's set to true - it indicates that function returns nothing and client won't wait for the answer. – sleepwalker Apr 26 '12 at 05:26
2

The .NET client code-generation tools have built in support for this-- you shouldn't have to manually generate asynchronous versions of every method.

If you're using Add Service Reference in Visual Studio, check in the dialog box near the top: there's a checkbox that says Generate Asynchronous Operations. If you're using svcutil.exe, then use the parameter /async to generate the asynchronous client methods.

McGarnagle
  • 101,349
  • 31
  • 229
  • 260
  • 1
    this is still not the best thing as you're just starting another thread from the service client instead of the service. if you truly don't care about the response marking the operation as one-way is the best thing to do. – nathan gonzalez Apr 26 '12 at 05:24
  • @nathangonzalez well, what Op is talking about is getting an asynchronous callback. If you want multiple instances of the service running, then that's what the *PerSession* and *PerCall* attributes are for. – McGarnagle Apr 26 '12 at 05:30
  • @dbaseman nope it doesn't work, i still need other function to return values, in fact the service already has PerSession `[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.PerSession)]` attribute. nathan gonzalez was right. – Murhaf Sousli Apr 26 '12 at 05:46
  • @MurHafSoz Did you read my answer above? Generating the Async service references creates a callback, which sends the result of the service method to your client **asyncronously**, using IAsyncResult. See here: http://msdn.microsoft.com/en-us/library/system.iasyncresult.aspx – McGarnagle Apr 26 '12 at 05:57
  • @dbaseman yea i read it and i did check Generate Asynchronous Operations. ,maybe it works for a similar issues, for me the best solution is to use a OneWay in `OperationContract`, thanks for the answer anyway :) – Murhaf Sousli Apr 26 '12 at 06:32
  • @dbaseman, his method example returns void, so a callback would be pointless as no data is being passed back. you just waste a thread locally waiting on the response. – nathan gonzalez Apr 26 '12 at 17:19