none
Non-Duplex Chunking Channel needed

    Question

  • I have an app that requires the transfer of some fairly large files between machines (the actual size varies, but let's just assume that it's not something we want to transfer in buffered mode).  The transfer may take place between machines that are both behind the same firewall, or it may occur between machines that are outside, being accessed across the Internet. 

    Up to this point, I've successfully used a modified version of the chunking channel sample to do the transfer over HTTP.  However, the chunking channel sample is implemented as a duplex channel, and this means that the client machine must expose an open port that is used when chunking the files to the client.  So something that uses a duplex channel isn't really a great long-term solution for this app. 

    I've created another binding that uses a TCP transport and the chunking channel, and this appears to work.  I haven't verified that it won't need the additional open port on the client, but in theory it shouldn't.  However, I really don't like the idea of using a TCP transport for this -- there are a number of reasons which I won't go into right now.

    What I'm really looking for is a chunking channel that will work with a wsHttpBinding and that doesn't use a duplex channel!  Is there a way to make a chunking channel that uses a standard request/reply MEP?  Has anyone done this?  Or am I asking for something that just isn't possible? 

    Any help would be appreciated.

    Thanks.

    Bruce Bukovics  http://www.bukovics.com
    Pro WF:  Windows Workflow in .NET 3.0 http://www.learnworkflow.com
    .NET 2.0 Interoperability Recipes http://www.interopbook.com


    Monday, August 20, 2007 6:27 PM

Answers

  • It sounds like your best bet at this point is a custom channel, either one your write, or one someone else writes.  The scenario you are looking for doesn't appear to compose well with what exists out of box for WCF, but then, thats what the extensible channel model was designed for I suppose.

    Monday, August 27, 2007 9:10 PM

All replies

  • Is there a reason you don't want to use the built in Streamed transfer modes?  For HTTP communciation they make use of chunking at the transport level so buffering wouldn't be an issue.

    Wednesday, August 22, 2007 6:15 PM
  • I've already tried the built-in support for streaming and it didn't serve my needs.  The streaming support works great -- as long as you never lose a connection or have any other communication issue during the transfer.  When you have a problem in the middle of a streamed transfer, it just doesn't recover well.  I've outlined some of the streaming problems in this earlier post:
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1735078&SiteID=1.  Basically I need something that is more forgiving of errors during transfer. 

    So I switched to the chunking channel instead of streaming.  And now I'm in the process of throwing out the chunking channel and starting over -- basically doing the chunking myself at an application level.  This is due to the issues I've outlined in this post.  I'm still interested in finding a way to do the chunking within the WCF stack instead of in my application -- but for my needs, it must not require a duplex channel.

    Bruce
    Wednesday, August 22, 2007 6:38 PM
  • It sounds like your best bet at this point is a custom channel, either one your write, or one someone else writes.  The scenario you are looking for doesn't appear to compose well with what exists out of box for WCF, but then, thats what the extensible channel model was designed for I suppose.

    Monday, August 27, 2007 9:10 PM
  • I am looking at doiing the same thing.  I was curious if you builit the customer channel and if so, how it was working out for you.

     

    Thanks,

    Matt

    Monday, December 03, 2007 6:22 PM
  •  

    I've done something similar, splitting the ChunkingChannel into an IInputChannel and an IOutputChannel so I can use it with NetMSMQ, providing the necessary exactly-once in-order delivery using my own persistent chunk storage mechanism rather than transport or protocol sessions.  I'll post more details once my hacks are fit for public consumption.  In the case of HTTP, you can probably accomplish this by just splitting ChunkingChannel into a ChunkingRequestSessionChannel and a ChunkingReplySessionChannel that implement IRequestSessionChannel and IReplySessionChannel respectively.  The various IDuplexSessionChannel methods from ChunkingChannel should split nicely between those two new channels.  Then you'll need to touch up the factory and listener as follows:

     

    ChunkingChannelFactory : ChannelFactoryBase<IIRequestSessionChannel>

     

    ChunkingChannelListener : ChannelListenerBase<IReplySessionChannel>

     

    and clean up the resulting type mismatch ripple effects, replacing references to ChunkingChannel with your new request-reply classes.

     

    If you get this working or run into snags, please post and let us know how it goes!

    Tuesday, December 04, 2007 2:36 AM
  •  

    Oran,

    Could you please provide me some code sample of what you described here.

    Thanks,

     

    Mark

    Friday, June 20, 2008 5:55 PM
  • I am also very interested in knowing more about this and whether the proposed solution worked.
    Thursday, August 12, 2010 9:57 AM
  • I just wanted to add that I've also been looking for a solution to do the same exact thing for over a year now. Unfortunately I haven't found a solution and I haven't had time to seriously look into writing my own custom solution either around the concept of chunking. I made a post on StackOverflow to look for some help on the topic so anybody who might be interested in finding a solution may also want to follow that post as it will be where I'll post any solution I come across.

    My hopes are that part of the next .NET Framework comes a built in capability to set up a service so that it returns IEnumerable<> and allows the results to flow over the service in a deferred manner. Making it simple to write this type of code over the various bindings included in WCF would make WCF that much more powerful.

    Thursday, August 18, 2011 9:58 PM
  • I also would like some followup on this technique. Is writing a custom channel complicated? How much code are we talking about to accomplish something that would be stable enough for production use.
    Tuesday, November 29, 2011 11:26 PM