0

FYI: This will be my first real foray into Async/Await; for too long I've been settling for the familiar territory of BackgroundWorker. It's time to move on.

I wish to build a WCF service, self-hosted in a Windows service running on a remote machine in the same LAN, that does this:

  1. Accepts a request for a single .ZIP archive
  2. Creates the archive and packages several files
  3. Returns the archive as its response to the request

I have to support archives as large as 10GB. Needless to say, this scenario isn't covered by basic WCF designs; we must take additional steps to meet the requirement. We must eliminate timeouts while the archive is building and memory errors while it's being sent. Both of these occur under basic WCF designs, depending on the size of the file returned.

My plan is to proceed using task-based asynchronous WCF calls and streaming mode.

I have two concerns:

  1. Is this the proper approach to the problem?
  2. Microsoft has done a nice job at abstracting all of this, but what of the underlying protocols? What goes on 'under the hood?' Does the server keep the connection alive while the archive is building (could be several minutes) or instead does it close the connection and initiate a new one once the operation is complete, thereby requiring me to properly route the request through the client machine firewall?

For #2, clearly I'm hoping for the former (keep-alive). But after some searching I'm not easily finding an answer. Perhaps you know.

InteXX
  • 6,135
  • 6
  • 43
  • 80
  • Well-thought-out it may be.. but it is **way** too broad for an SO question. – i3arnon Sep 29 '15 at 20:42
  • @i3arnon: Aha. So be it. I'll take my knocks. But the downvoter should at least explain why, so as to be constructive rather than destructive. Maybe I'll withdraw my criticism of anonymous downvotes; I suppose I'm not so much interested in who as I am in why, so I can do better the next time. I understand the potential for petty retaliation, especially after reading [this](http://meta.stackoverflow.com/q/253531/722393). – InteXX Sep 29 '15 at 20:45
  • Probably belongs @ http://programmers.stackexchange.com as a conceptual question – ivan_pozdeev Sep 30 '15 at 00:37
  • 3
    @ivan_pozdeev: Too broad is too broad everywhere. – Robert Harvey Sep 30 '15 at 01:14
  • @RobertHarvey O RLY? Software design decisions are a broader topic than individual implementation problems, aren't they? And Programmers seems to exist specifically for those if http://programmers.stackexchange.com/help/on-topic is still correct. – ivan_pozdeev Sep 30 '15 at 01:21
  • 1
    @ivan_pozdeev he has 100k reputation on programmers.stackexchange, I think he knows and understands the scope there ;) – enderland Sep 30 '15 at 01:22
  • 1
    @ivan_pozdeev - you fail to account for the fact that you may have misunderstood that page. This is too broad for Programmers. –  Sep 30 '15 at 01:23
  • @enderland Maybe. But if he does, this means I don't. – ivan_pozdeev Sep 30 '15 at 01:23
  • 2
    @ivan_pozdeev - As one of the top close voters on Programmers, I'm going to have to go with Robert understanding what he's talking about and you being mistaken. Have a read of http://meta.programmers.stackexchange.com/questions/7182/what-goes-on-programmers-se-a-guide-for-stack-overflow and always feel free to drop by in The Whiteboard if you think there's a question here on SO that really belongs on Progs. –  Sep 30 '15 at 01:25
  • @GlenH7 thanks, the link is much useful. The phrase "too broad is too broad everywhere" is plain logically false still. And I still [fail to see how this is not a valid design question](http://meta.programmers.stackexchange.com/questions/7182/what-goes-on-programmers-se-a-guide-for-stack-overflow#comment22974_7183). – ivan_pozdeev Sep 30 '15 at 02:51

1 Answers1

2

You need streaming for big payloads. That is the right approach. This has nothing at all to do with asynchronous IO. The two are independent. The client cannot even tell that the server is async internally.

I'll add my standard answers for whether to use async IO or not:

  1. https://stackoverflow.com/a/25087273/122718 Why does the EF 6 tutorial use asychronous calls?
  2. https://stackoverflow.com/a/12796711/122718 Should we switch to use async I/O by default?

Each request runs over a single connection that is kept alive. This goes for both streaming big amounts of data as well as big initial delays. Not sure why you are concerned about routing. Does your router kill such connections? That's a problem.

Regarding keep alive, there is nothing going over the wire to do that. TCP sessions can stay open indefinitely without any kind of wire traffic.

Community
  • 1
  • 1
usr
  • 168,620
  • 35
  • 240
  • 369
  • 1
    The routing was going to be a problem if the connection was going to close. From your answer, it doesn't appear that it's going to be an issue. I didn't know that about TCP, thank you. Good info. – InteXX Sep 29 '15 at 21:21