Custom Transport Retry Logic

New and Notable 200

Sam Gentile — Mon, 05 Nov 2007 23:40:31 GMT

Finally! Its taken me like 5 years to get to 200. I sometimes I wish I was prolific like Mike Gunderloy

Detecting ASP.NET Compatibility

Nicholas Allen's Indigo Blog — Tue, 06 Nov 2007 00:28:40 GMT

How can I find out whether my service is running in ASP.NET compatibility mode? Why do you need to detect

New and Notable 201

Sam Gentile — Tue, 06 Nov 2007 19:38:20 GMT

SOA Nick has his fourth post in a series on the impact of the business operating model on Service Oriented

re: Custom Transport Retry Logic

Wed, 07 Nov 2007 01:00:20 GMT

Well thanks to my luck I see this as an entry just as I was wondering how on earth does WCF deal with something simple like NetTcp channel experience a transport failure without diving into ping-like and retry/reconnect logic.

So is it at all advisable for it to be a part of the contract?

re: Custom Transport Retry Logic

Wed, 07 Nov 2007 01:12:27 GMT

Also, looking around I can see various timeout properties available for reliable nettcp config but also notes that there are bugs around. I am no longer confident WCF will work in the following scenario.

In short, what I am looking for is an explanation of how an endpoint can continously callback into a client (ideally not a poll but a stream), over whichever NetTcp binding is required. How does WCF do that, can it detect on either and both ends (via an exception I presume) that an 'underlying transport' (aka TCP connection) has been lost (router, path problem, cable plugged out etc). It can be a failure on any side, for any reason, but I am looking for a stream-like behaviour and not RPC that is buffered.

Is there such a feature at all?

Thanks in advance.

re: Custom Transport Retry Logic

Nicholas Allen — Wed, 07 Nov 2007 07:45:00 GMT

It's not possible to have reliable transmission without buffering data.

If you want reliable transmission, then that's exactly what the reliable session channel does. Those are the knobs that you see in the NetTcp binding. A reliable session reestablishes the connection and replays the data that didn't get through. You can use chunking to make the size of the buffers smaller and approach a more stream-like behavior.

If you want streaming, then that's exactly what datagram channels like HTTP and UDP do. You can keep sending messages and while they may or may not get there, the underlying transport gets reestablished whenever the next message is sent.

New and Notable 201

Sam Gentile's Blog — Wed, 03 Dec 2008 03:16:31 GMT

SOA Nick has his fourth post in a series on the impact of the business operating model on Service Oriented Architecture with SOA in the Replication Model Microsoft My collegue Mickey Williams has posted that Microsoft Search Server (MSS) 2008 and MSS