views:

430

answers:

3

Hello,

During development of client-server system using .NET Remoting (.NET 2.0) for communications I found extremely weird behavior if my remoting objects return custom datasets. For some reason it takes from 0.5 to 4 seconds for remoting infrastructure to process an empty dataset instance on the client side, if I'm using TCP channel with binary formatting (the fastest option!). The behavior exhibits in the following way: after clean start client may make only so many calls to the server getting custom dataset within tens of milliseconds; once resting for 4-5 minutes (no calls to remote side during this time), each and every consequent call to remote side returning custom dataset takes 0.5 to 4 seconds. If remote call returns anything else except custom dataset, everything performs in tens of milliseconds again. If I change my remoting configuration to HTTP channel with binary formatting, everything works flawless. I use this configuration as a workaround, but this is not the solution, but workaround.

Custom dataset is made by creating a new XSD Dataset and dragging a table from Server Explorer (SQL server), then removing table adapters part from the dataset.

I created a bare-bone test project (download) which exhibits the behavior I'm talking about. I included ReadMe file with steps on how to reproduce the problem.

Thanks!

PS. This was an original question, but now I narrowed it down to custom datasets, which are apparently a culprit, so please don't mark it as a duplicate.

A: 

Check out this article and make sure your serializing the dataset's using the correct format. http://msdn.microsoft.com/en-us/magazine/cc163911.aspx

JoshBerke
A: 

I came across the article about serialization format during my research. That's why I have this case as a separate option in my test project. Adjusting BinaryFormat manually increases processing time from 0.5 to 4 seconds.

+1  A: 

You could try some of the steps from this article, I've used some of them before and it had a massive improvement.

Kieron