GUIDANCE NEEDED: trying to determine simplest way to implement custom server-side TCP-based transport + encoder

Question

Hi to all WCF gurus with experience creating custom transport channels! 

We would like some help/guidance on creating a "simple" custom server-side TCP transport and encoder.  Here are the requirements:

* java client using TCP sockets to send request to our .NET service using the custom TCP transport + encoder
* we must handle multiple concurrent requests and send the replies back
* we do not require any other layers other than our transport and encoder

So, based on this, we originally thought we just needed to implement a custom IReplyChannel shape, but we are not sure.  There was some confusiong about whether we needed a Sessionful Channel or not.  We are not maintaining state across multiple requests, so I would think we do not need this.  Can someone clarify this statement: you don't need a session to process multiple requests concurrently [like we need to do]?

If the requirements above are enough to determine the minimal parts we must implement, we would greatly appreciate any guidance.  If you need more information, please ask.  I have searched for Kenny Wolf's link on determining the proper WCF channel shape, but cannot find it any longer.

As an FYI: We have created a prototype with two console apps to try and isolate the functionality and make this as simple as possible and actually got a request to be processed and reply sent, but are seeing some un-expected calls on the server side that cause the app to crash.  As a result, we are pretty sure we have not implemented this correctly. 

We have used whatever information we could find in various books, online resources and links from Kenny and Nicholas.  Unfortunately, we're still struggling.   

Thanks in advance,
Bob

Answer 1

-> we do not require any other layers other than our transport and encoder

Sounds like a pool of TcpListener or listener socket should be enough for your scenario, since the infrastructure WCF builds around service model layer, messaging/framing layer, and transport layer doesn't buy you any benefit in terms of implementing plain TCP server, or I misunderstand your scenario?

Thanks

---

Another Paradigm Shift
http://shevaspace.blogspot.com

Answer 2

If you're suggesting we not use WCF at all, I should have mentioned the following in my original post:

I should add that we want to keep this implemented within the WCF stack because we are using a service-oriented approach and expose this functionality through multiple endpoints.  There are actually two custom protocols - both TCP-based, and we anticipate exposing the built-in http endpoint in the future.  The custom transports are for our own proprietary software which receives a huge performance gain over text [or even MTOM] over http for the amount of data we may be returning from the service.

As a result, I was hoping to implement these custom transports in a pluggable way - so our WCF-based architecture would support both standard as well as our custom protocols for legacy applications.

Thanks,
Bob

UPDATES:

* we have a prototype that uses the IReplyChannel, but we are randomly seeing a 2nd call to the IReplyChannel's Abort call.  We are not sure what is making this happen.

* Please ADVISE if I should keep this here or move this to one of the managed newsgroups.  Since we have MSDN subscriptions, I would like to use the quickest mechanism to get this answered.  If newsgroup, please specify which one, since there is no managed newsgroup specific to WCF.

Answer 3

-> As a result, I was hoping to implement these custom transports in a pluggable way - so our WCF-based architecture would support both standard as well as our custom protocols for legacy applications.

Thanks for this clarification, your original statement "we do not require any other layers other than our transport and encoder" makes me think that you only need to implement the communication part of WCF, rather than the rich servicing model WCF builds on top of the communication stack.

-> if I should keep this here or move this to one of the managed newsgroups.  Since we have MSDN subscriptions, I would like to use the quickest mechanism to get this answered.  If newsgroup, please specify which one, since there is no managed newsgroup specific to WCF.

I think you might have better luck asking this question at the .NET Framework general discussion newsgroup, as a side note, the newsgroup and forum will eventually merge into a single support platform within months.

I have to admit that I've never written custom transport in WCF before, so I have to admit that I cannot suggest any more except the already well-known UDP sample which only supports IOutputChannel and IInputChannel as the nature of UDP protocol indicates:

http://msdn.microsoft.com/en-us/library/ms751494.aspx

Sorry for the unhelpful reply.

I will try to loop someone from the WCF team to help you since there is a great chance that you might not get the desired answer from the managed newsgroup.

Thanks
Marco

---

Another Paradigm Shift
http://shevaspace.blogspot.com

Answer 4

Thanks Marco!

I have posted my question to the microsoft.public.dotnet.framework newsgroup under the following posting:

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework&mid=d12f38a0-3ee2-4708-bdb3-b8e9cbe11de6&sloc=en-us

I have re-worded this to focus on the problem we are now seeing, since we have a prototype working pretty well, but are occassionally seeing a random problem.  If you can direct some of the WCF guys to look at this and possibly help us out, that would be great.  In fact, we can provide this prototype with instructions on how to see the problem if needed.  We took the code out or our product so we could isolate it without worrying about any IP issues.

Thanks again,
Bob

Answer 5

Hi Bob,

Let me know if you got solution or not, I've tried to loop some one from the WCF/Transport team for idea, but apparently, they have their own agenda, if you finally got the solution, I greatly appreciate it if you could share the solution out. If not, I could still trying to keep on eye on this forum thread for solution.

I am writing reply so that this thread could be bumped up again to get the attention of other community members:)

Thanks

---

Another Paradigm Shift
http://shevaspace.blogspot.com

Answer 6

Hi Marco,

We ended up going with a simpler approach - since we control both ends of the custom tcp-based communication.  We couldn't get the custom transport working reliably and could not troubleshoot it [since any logging seemed to slow it down enough that the problem didn't occur].  As a result, we decided to simply implement our own custom socket server listener in our process - alongside the WCF hosting.  This seems to work fine and since we aren't using any other parts of the WCF stack for this channel anyway, it should be the best performing solution, too.

Regards,
Bob

Answer 7

I don't know if non-MS people can suggest solutions here too or if the inquirer cares about what others say as well but I have a sample solution that you might be interested if it's not too late.

You can download it from here: http://sites.google.com/site/jeffsaremi/codedownloads/SdcCommService.zip
It has a custom listener, reply channel, encoder, and more.
You can choose to eliminate the "more" but I don't think you're problem would end in just a listener and an encoder.
You have to bring the request into at least one central location (see my dummy service) and then from there do whatever you want outside of WCF.
Or may be you can if you format your messages exactly like what WCF expects.
Anyway you're welcome to use this.
jeff