As I talked about recently, the standard binaries for db4o have some issues with mono, so I recompiled the unmodified source with the MONO configuration flag. I’ve packed up both the debug and release binaries and you can get them here. These are just the binaries (plus license). It’s not the full db4o package. If you want the full package, just get it directly from the db4o site, since the MONO config flag and have Visual Studio rebuild the package.

This package should show up on the official db4o mono page shortly as well.

I just read what’s got to be my favorite Miguel De Icaza quote to date:

In a world that is increasingly green, it is a waste of perfectly healthy computer cycles to interpret your code when you can use an optimizing JIT compiler to run your code.

I’m going to presume that’s with tongue firmly implanted in cheek.

Experimented with System.Security.Cryptography.RSACryptoServiceProvider last night to see if i could use it for Public Key encryption between .NET and Mono. Worked flawlessly.

This goes back to my networking thread. I’m currently contemplating using PKI to establish trust relationships between peers. For the sake of this discussion, there is a serving peer, the one that is connected to, hereafter the server, and a client peer, the one that makes the connection, hereafter the client.

Each peer keeps the public keys of its trusted peers. When a client connects it sends its own public key to identify itself. The server first checks whether it trusts that public key at all, then, having passed that test, encrypts a packed containing a random string, plus its own public key with the client’s public key. Only the true owner of the public key can decipher the message.

Now it’s the client’s turn to check whether it in turn trusts the servers public key. If it trusts the public key, the client encrypts a new packet containing the original random string, plus one of its own divising with the server’s public key and sends this back. Again, only the true owner of the public key can decipher the response to its own challenge.

Decrypting the package the server can now verify that the client is truly the owner of the public key, and finally it sends the client’s random string back encrypted with the client’s public key as acknowledgment of its trust and affirming its own identity to the client.

At this point the client should send all the public keys it trusts to the server and the server responds with the subset it trusts as well . Now we have a relationship that allows the peers to trust each other and know what information they may pass on directly, given the others level of trust and what information it would have to proxy, being the trusted intermediary.

I don’t know if I’m re-inventing something obvious here. It seems fairly similar to the SSL handshake, except that I don’t care about encrypted communication, and therefore don’t use SSL. I just want to establish trust on connect.

After my TCP toying I decided to do some Remoting experiments last night. One of my goals with the network programming i’m doing right now is that the business logic of the code should be portable between .NET and Mono. I know Remoting is a probably not the answer there, since it may not even stay compatible between .NET revisions.

Regardless, I tried it out and it worked great between Linux and Windows. Nice, simple elegant (with a fair share of black magic under the hood). The only pitfall I came across was that if you are using RemotingConfiguration.RegisterActivatedClientType(), you gotta make sure that the type you are using comes from the same assembly on the two platforms. I had a bunch of problems because I compiled the Windows and Linux versions differently at first, but then i just copied the Assembly that contained the classes to be remoted to the linux side and compiled against it. That did the trick.

Now, is there something inbetween Remoting and writing my own protocol with TcpClient for doing Client/Server communication? More research for another night.