/bill's House O Insomnia : Remoting

If you want to prove you're a real programmer

William — Mon, 07 Nov 2005 22:51:00 GMT

Benchmarking things like this and this is definitely one way to do it. I shouldn't be surprised though, Roland has been rolling in cool posts and projects recently.

Requests for Content

William — Mon, 24 Jan 2005 04:40:00 GMT

I've finally started to get a little free time these days and I'm going to be doing some quality Travelling in the next few weeks - if you're interested in something in particular, I'm taking requests. Anything ADO.NET, Anything Compact Framework, (Not that I'm qualified on these two - but I'll give it a try).

Bill

BinaryFormatter in ADO.NET 2.0

William — Mon, 24 Jan 2005 04:26:00 GMT

This is hardly hot off of the press, but I had a few questions about it and figured I'd post it. There is a new RemotingFormat property w/ DataSets in ADO.NET 2.0 - and depending on how you are trying to work things, the differences can be profound. Note that when I use 10 records, the XML version is 1kb whereas the Binary is 7kb - but my how quickly seasons change.....

SqlConnection cn = new SqlConnection("Server=PimpDaddyServer;Integrated Security=True;Database=AThaWayThug");

SqlCommand cmd = new SqlCommand("SELECT PimpID, PimpName FROM Thugs WHERE PimpID < 1000", cn);

SqlDataAdapter da = new SqlDataAdapter(cmd);

DataSet ds = new DataSet("Pimpin");

da.Fill(ds, "AintEasy");

ds.WriteXml(@"C:\sizetest.xml"); //94kb @1,000 - 955kb @10,000

ds.RemotingFormat = SerializationFormat.Binary;

IFormatter Formatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();

Stream myStream = new FileStream(@"C:\sizetest.bin", FileMode.Create);

Formatter.Serialize(myStream, ds); //24kb @1,000 - 196kb @10,000

Extending .NET Remoting

William — Wed, 22 Dec 2004 05:58:00 GMT

If you use .NET Remoting then you no doubt know the name Ingo Rammer. Ingo's book is to Remoting what David Sceppa's book is to ADO.NET. I was fortunate enough to receive a few advance chapters of the Second Edition and I'm totally impressed. Apress is doing some really wonderful work and I think I'm 1-1 on Apress books I read vs. Really Loved.

The chapters I read are on Extending .NET Remoting. When I first came across it in Ingo's first book - I kind of chickened out. That's really the only word for it unless you want to get crass. I had some nightmare experiences with DCOM and Windows DNA and it left me with a bad taste in my mouth. So I shyed away from Remoting totally - until I moved to TiBA and under the tutelage of Phil Hunt - learned that there's more to fear by not using Remoting then there ever is by using it. Phil and a few of my other co-workers really helped me out at first, and Ingo's book was always there to help me understand the theoretical aspects of why things worked the way they did (or in my case - why things didn't work the way they should have). So when I started reading about writing my own sinks - my inner chickensh1t came out and I came up with 1000000 rationalizations on why I didn't need to bother with such stuff quicker than you can blink.

However that is a quirk of my personality - I am quick to write stuff off if I don't think I can get it - and then immediately I start telling myself what a pu55y I'm being and usually end up going gangbusters on it. This happened with Remoting big time.

I don't want to delve too far into the subject without checking with Apress first but since he's touched upon all of this in the first book - I don't think it's a big deal.

Let me start out with an analogy. Most of us know a 'know it all' programmer who is all about the latest greatest thing. They usually are the first out of the gate on anything that appears in MSDN Magazine or Slashdot and they usually have some degree of talent. More often then not though - they are usually what my friend Caustic Phil refers to as Blunderman (Incidentally - if you were wondering why Phil doesn't blog much anymore I have the answer. His wife is a Goddess and they are newlyweds - you can do the math). These are the types of folks that can recompile their kernels (or so they tell you every day) but can't seem to get away from overwriting array boundaries or putting exit conditions in their recursive algorigthms.

Well, being able to Remote an object from one machine to another is worth about the same as this if that's as far as your Remoting game goes. You'll definitely sound like a big shot at User Group meetings. You'll definitely have all of the VB6 guys who've just come over to .NET oooohing and aaaahing over your game. You'll definitely be able to criticize any architecture that isn't real n-tier and intimidate folks that are pure client/server types. But if you don't look further into learning Remoting, you'll basically be a lot of hot air with a good parlor trick. If you Read Ingo's book though - you can save yourself from this fate. Remoting, just like Web Services, is great for tasks that it was designed to do. It can be very easy to implement and can work wonders for your apps with very little effort in some scenarios. It's precisely because it's usually so easy to get up and running that it can make you think you're better at it than you really are. In many instances, you may design a really complex architecture that looked really cool in Visio - but is sluggish and unresponsive in practice. At this point - You will NOT LOOK GOOD No matter how much Buzzword Bingo you play. In order for Remoting (or anything else) to be of value, it needs to provide functionality that wasn't there before, or greatly enhance what was there while making it easier to develop and debug. My point is simply that in and of itself, no technology has value. It's value totally resides in your ability to solve problems with it and ostensibly do it in a better way than was done previously. And just like threading - Remoting can SAVE the day in many scenarios - but if you don't understand what you're doing and why it's working the way it is - you're likely to be headed for trouble. Fortunately, these disasters are largely avoidalbe if you do your homework.

So why would you want to extend remoting? (I'm paraphrasing from Ingo's first edition - page 249 - Chapter 9)

Compression/Encryption
Passing additional information. In my opinion - this is one of the more important cases. Ingo uses the example of passing the client-side thread priority to the server so they can both be performed using the same thread priority.
Extending the look and feel of .NET Remoting. He mentions using a Per Host authentication model vs. a per object model. This seems to be one of the weaker arguments IMHO but I'm not really qualified to write it off. It just seems from what I've been exposed to, that this is a solution that adds a fair deal of complexity without an equal amount of value - at least in most of the cases I've come across. Again though - my experience with Remoting started in August of this year so there's a good chance I just haven't run into a scenario where this would be a big issue
Debugging your apps and sending the message contents to the console window or a logger. This is not something I'd want to do on a application by application basis, but building some internal components that will be reused over and over makes this well worth doing IMHO.
Custom Sinks and Providers. Well - you saw how I went gaga over Sahil's MSMQ Data Adapter or N Software's ADO.NET Provider which can read RSS Feeds for instance.

Of the lot, I think the last one is the most cool/fun but probably not the most necessary - there's plenty of native support to push things back and forth over the wire as they stand now. However changing things over to a MSMQ implementation could definitely be useful in more than a few cases - and hopefully over the holidays I'll have some time to work with it a little more.

The most practical IMHO regards Compression/Encryption and Debuggging. I've worked through his Encryption/Compression example originally and then through what was done on the updated work. It's pretty straightforward to get working - and unlike a lot of other remoting stuff - I got it working with very little hassle. I think that's mainly because the real 'bitch' of remoting is getting everything right in your configuration files ;-) To use the Compression example, you need to use Mike Kreuger's SharpZipLib which is pretty helpful - or if you want to be a little more ambitious - you could write your own. He runs through a comparison/proof -of-concept that illustrates a pretty dramatic decrease in size once you use the compression sink - and if you chose to do it in Binary you'd see even more of a difference.

To get this part working it'll take you about 20 minutes to an hour assuming you are somewhat familiar with Remoting Configuration and Remoting in general. However the Encryption section is what really rocks. It's definitely a more complex area and something you need to put a little more thought into - but it's covered in a component based way - so once you write it once - you can reuse it all over the place - an investment of time I think is well worth it.

Instead of regurgitating everything, I should probably finish up the encryption piece and walk through it. I give you fair warning - covering some of the more advanced areas of Remoting makes you quickly realize how much power you have with it - and that power - can be as addictive as crack. (Something tells me that when i finally fall asleep around 4:00 am - I realize how addicitive Remoting really is).

Andres on Remoting Datasets...

William — Thu, 16 Dec 2004 18:40:00 GMT

Andres Aguiar , the superbrain behind Deklarit responds to Rory's comments on Stuart's post.

<<As I cannot comment in Stuart's blog, I'll do it here ;)

a) He's right about that if you are not going to update data, then it's probably not a good idea to use a DataSet, unless you only want to use it with .NET clients and are willing to pay the serialization overhead.

b) He's wrong with the DataSet/Database coupling one. A DataSet does not need to be coupled with the database, it can have any structure. I can return a DataSet even if I don't have a database in the backend.

c) The argument about sharing types is also weak. Check http://www.25hoursaday.com/weblog/default.aspx?date=2004-06-03 for an interesting point of view. In DCOM you _cannot_ invoke a service if you don't have the type. In WebServices with a DataSet, you can, even if you are in Java. Also, if you return a typed dataset, you don't need to have the same _type_ on the other side of the wire, just an equivalente DataSet. >>

.Config files are a touchy lot

William — Tue, 02 Nov 2004 04:27:00 GMT

The more I dig into what all you can do with app.config/web.config, the more I love them. When i first started using them I thought they were little more than a glorified .ini file - with some xml thrown in to make people feel cool b/c they could say they were using XML. Chalk one more up in the “stupid things Bill thought” column. The only problem with them (other than the fact that if you aren't editing them by hand our outside of your app, they are a little annoying to deal with) is that they are really fussy. <Appsettings></Appsettings> isnt' going to work for you and when you're editing in XML - it's easy enough to overlook something and make a typo - especially when you have a ton of sections in your file. But today, as I'm staring down a really important deadliine and stressed to the hilt took the cake. I built a new assembly to handle the DALC stuff for one of the pieces of the project I was working on. I built the interface and all looked good. Added the entry to the .config file and registered it as a well known type. Then I tried to use it and got the famous TypeName cannont be resolved to a local type error. So I checked to make sure the assemblies were being copied correctly with Post Build events, double checked my syntax and everything else I could think of. Nothing worked. After about a day of trying to track it down at different times, I finally figured it out. When I was registering a WellKnown Type , I put a space between the last letter of the class name and the comma that separates it from the Assembly name. Made that change, life was good. One stinking space between a comma was all it took to bust my ba113 all weekend. But, in the words of Poison or one of those cheesy glam bands, Every rose has its thorns - as is the case with .config files.

My first stab at a Remoting Article...

William — Thu, 28 Oct 2004 05:00:00 GMT

Last night I broke down and wrote my first remoting article. . It really made me appreciate what it takes to be a good writer because I'm not one. take a subject like remoting for instance. Where do you really start? Many people think that breaking stuff into .dlls is 'multi-tiered' and I've met a LOT of folks that think this is the case. So the pitch for remoting falls upon deaf ears. Until they actually are confronted with having to move stuff to different machines and run them accordingly, they won't really see that hard coded .dlls won't cut it. Then the next crowd is the 'web services are easy' so I'll make a web service out of it. (I'm not in any way implying that Web services are easy or that people that use web services are lazy - far from it). The problem is that with .NET, it's pretty 'easy' to do a lot of things, but doing things securely, efficiently and that scale well is a whole different issue. Some folks won't see this until they deploy and have the thing not work well.

After you get through this hurdle, there's the real part, namely the technical nuances of remoting. Trying to explain the difference between client activated and server activated objects wthout having someone see them both in action is pretty tough. I read about them quite a bit and never really got it until I started working through them. Then there's hosting the things. Then there's securing the stuff. So it's pretty hard to write about without doing a lot of background explanation which is what sort of muddles the water for a lot of people. Anyway, I'm thinking that if I do like a 5 part series on it I can probably touch upon a lot of the everyday stuff you come across. Then again, I'm still fairly new to remoting so I myself have a lot of learning too.

Cross Platform Programming

William — Sun, 24 Oct 2004 22:54:00 GMT

Just to give you an update on the project ----- so far, it looks like Portable .NET is going to be the weak link. I'm not criticizing it, but the implementation is a little small compared to Mono and obviously the full framework. I am not in any ways or by any means 'qualified' to say what can't be done with it because prior to last week, I hadn't looked at it. I'm fairly familiar with Mono (which is impressive) but my Linux game is mud and I haven't found too many Linux wizards that I can go to for help. Found a lot of guys that can recompile their kernels but other than that, getting help setting up Samba to work correctly got me nowhere. And to be honest, if I can get Samba running but some guru capable of rebuilding his kernel can't, his guru status is a big question mark. Anyway, my point was that I've never used a Mac until this last week (well, I had a Lisa and a IIE but I don't think that counts) and any deficiencies I come across in Mono are probably due to deficiencies in me, not Mono. That's the story until I get a lot more familiar with it anyway.

I don't see Remoting support the http://www.dotgnu.org/pnetlib-doc/ for Portable .NET but that doesn't mean it's not there or not in the works. (Geez Bill, can't you find a way to say you don't know what the hell you're doing in less than 200 f****** words). Well,actually no. In order to really discuss this stuff you need to compare all three and not knowing ofe of them kind of hinders that. So far though, I have been able to get the WS stuff to work with each build. That seems like the easiest of the bunch though.

Next, I'm going to change the strategy. First pass will simply be remoting something from Windows to Linux. Then I'll use a WS to transfer the data over to the mac. Not exactly what I wanted to do but I have to compromise for the moment. Another issue is heading over to dotgnu. It's a weee bit too Anti-Microsoft for my taste and when I see this sort of stuff, well, it reminds me of the type of people I've known that usually talk like this. Big, fat, long hair, a bunch of stupid tatoos and earrings, wearing black w/ a graphix bong next to the TV. In the back of my head is this continual drumming of “Do you really want to ever hang out with these people?” Then I tell myself that my impression was created using a pretty broad brush and that's certainly not the norm. Oh well

Anyway, I think I have the Mono Scenario under control - got a long way to go with Portable .NET. If anyone out there is using Portable .NET, please drop me a line - would love to run a few things by you.

Tricky Exception Message while Remoting...

William — Mon, 27 Sep 2004 00:49:00 GMT

Well, as you may know, I've recently taken a position at a new company. We are doing some really really cool stuff which, amongst other things, takes advantage of .NET Remoting, Service Oriented Architecture, MSMQ, Biztalk Server 2004 and Web Service Enhancements (WSE) 2.0 to name just a few. Well, fortunately we have some really brilliant developers who've helped me out quite a bit getting up to speed with what used to be a big weak spot of mine, Remoting.

So recently I was working on a few components and since they were pieces of our communications layer, they of course needed to be Remotable. If you aren't familiar with Remoting yet, you really owe it to yourself to learn it. I've avoided it for almost 3 years now and am quite embarassed that I did so. Ignoring the communications layer is something you don't want to do in any 'real' distributed environment. I'll be getting into the how's and why's shortly in some new articles I'm working on, but for the time being, trust me on this one. Anyway, I had gotten through about 60% of what I had to do and essentially I was using a reference to the .dll where I created my objects first to make sure they worked, then I removed the references to them, added a reference to their interfaces and remoted them. All was going well until I got to one of the SIMPLEST ones I had - it was simply a collection of Message Queue objects with some other custom information.

There was nothing fancy about this and everything else had been working. But each time I tried to create the object, I recieved a System.Runtime.Serialization.SerializationException with the following information:

"An unhandled exception of Type 'System.Runtime.Serialization.SerializationException' occurred in mscorlib.dll. Additional Information: BinaryFormatter version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552'.

So I immediately took it at face value and figured I must have screwed something up in my .config file and specified the wrong Formatter Type. This didn't seem likely though because I didn't remember even writing any formatting information into the .config since well before this problem showed itself. Nonetheless I double checked my config settings and everything seemed correct. So I decided to check out google and came across this article from the Jedi Master himself. I had already read his book and didn't recall any mention of what this could be. After reading through the article I could safely conclude there was a problem here. Furthermore, I figured I'd stop wasting my time looking for problems related to the formatter - after all, he pretty much convinced me that the exception information was completely misleading. So, I decided to take his advice, use PocketSOAP and see what the server was returning. (This in and of itself is a bit of a daunting task at first, but I ASSURE YOU, it's well worth the effort because you'll learn a lot just walking through the excercise). Right there, clear as day was the source of my problem.... The assembly XXXXXXXXX wasn't found, and for good reason, the assembly name was XXXXXXXXXXXY. Even though I thought I carefully checked the spelling, the IDE doesn't typecheck your config entries so they are very prone to typos (which I make quite a few of). So I corrected the typo, tried again, and Boom, I'm off to the races. The reason I write this is mainly because this is one of those problems that can really give you some headaches. First off, you are probably going to try tracking down something that has NOTHING TO DO with the problem. So you may well change a few things (that work) all the while wasting valuable programming time. This is further reinforecement of the fact that if you don't know why you're changing something, you shouldn't change it. Furthermore, it reinforces the notion that you ought not to be using things that you don't understand and that taking time to really understand why things work the way they do will make your programming career a WHOLE lot better. And finally, although Ingo's article definitely tells you what the problem Isn't and how to find it, well, it puts the burden on you to figure out the rest.

If you've never read a tcpTrace then this might seem really too much to deal with. So to that end, I'll tell you that IF YOU'RE GETTING THIS ERROR

1) VERIFY THAT YOU'VE SPELLED EVERYTHING CORRECTLY

2) VERIFY THAT YOU'VE FULLY QUALIFIED YOUR NAMESPACES

3) MAKE SURE YOU AREN'T REFERENCING AN ASSEMBLY NAME WHEN YOU SHOULD BE REFERENCING AN OBJECT NAME, AND VICE VERSA

Ingo's article will give you everything you need to find this on your own and if you find that you just simply mispelled something or misreferenced it, I would still HIGHLY encourage you to walk through the process that he puts forth. After all, in this case it was easy to find the culprit but don't be lulled into thinking that this will always be the case - in all likelihood it won't. .NET Remoting isn't 'impossible' but it's also something that like threading, should be understood before you try to use it in production. There's a lot that can go wrong and tracking things down, particularly if you use the configuration files to set everything up (which trust me - is the only real way to do this), can be a good amount of work.

Finally, since Remoting is quickly becomming one of my new passions, I'd really like to hear your opinions/problems/likes/dislikes/troubespots etc - please write me at Bill AT KNOWDOTNET DOTCOM. I'd really like to hear from you. I'm going to do my best to discuss the pitfalls and roadblocks you may come across when learning Remoting so any and all feedback is greatly appreciated.