Skip to content

Iloggable

  • in net
  • 1 min read

Fun with enum bitflags

I've previously learned about the enum [Flags()] attribute, but had forgotten usage and reference to it isn't the best, so i figured, iput this down before it slips my mind again.

Say you want a compact way to store a bunch of boolean flags but you want it to end up as human readable code and you don't want to deal with binary operations. Step 1) use an enum for your flags and give the enum the [Flags()] attribute. Now you have a human readable flags, but you still have to do bitwise operations on them to set, unset and get these flags. So, wrap the whole thing in a struct giving a boolean property as accessor for each flag.

struct ByteFlag
{
  // Internal storage of our flags -----------------------------
  [Flags()]
  enum flags : byte
  {
    IsCool = 1,
    IsTasty = 2
  }

  flags bf;
  // Initialize, set and retrieve the underlying storage ------
  public byter(byte pInit)
  {
    bf = (byteFlag)pInit;
  }
  public byte ToByte()
  {
    return (byte)bf;
  }
  public void FromByte(byte pValue)
  {
    bf = (byteFlag)pValue;
  }

  // Accessors ------------------------------------------------
  public bool IsCool
  {
    get { return (bf&byteFlag.IsCool)==byteFlag.IsCool; }
    set { bf = (value)?bf|byteFlag.IsCool:bf&~byteFlag.IsCool; }
  }
  public bool IsTasty
  {
    get { return (bf&byteFlag.IsTasty)==byteFlag.IsTasty; }
    set { bf = (value)?bf|byteFlag.IsTasty:bf&~byteFlag.IsTasty; }
  }
}

Now you can do store that flag in a byte and when you want to manipulate the flags it's as simple as:

ByteFlag byteFlag = new ByteFlag(theByteOfStorage);
byteFlag.IsCool = true;
Console.WriteLine("IsTasty: {0}",byteFlag.IsTasty);
  • in geek
  • 1 min read

Could you please sign this?

Right, so i started thinking I'm doing too many trips, because the client and server could just sign their packages. But that doesn't actually prove anything. After all, someone could have just connected to a server, received their package and then used it to respond to someone connecting to them. That way they'd be pretending to be the other server. The package would be validly signed but not prove the servers identity. Basically we do still need the random phrase challenges from both sides

This does bring up the whole Man-In-The-Middle problem. I could still simply become a proxy between two peers. Not wanting any central service for registering, I'll probably just go with adding the IP in both the client and server packets. That way we can check that the message originates from the same IP we're talking to.

  • in net
  • 2 min read

RSA PK encryption with .NET and Mono

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.

  • in net
  • 1 min read

EnvDTE going nowhere

Ok, no answers on my quest on what I can cast Events to. No matter, I can always add better support for Events later. Time i get back to it and start adding "add code" drop downs to the code browser. We'll see how it goes from there

  • in geek
  • 1 min read

MacMini, the next set-top box?

Ok, not quite programming, but close enough.

I was looking at the MacMini and were I not only invested in using my chipped Xbox with XMBC, I'd seriously consider a MacMini as my Media Center. I mean it's perfect:

  • Has DVI out, easily connectable to my HDTV for high res output
  • Has a DVD player and a DVD drive
  • Is tiny
  • Is ultra quiet
  • Runs iTunes, and all things XMBC considered, iTunes is still the best music player
  • Has BlueTooth for all sorts of remote control options, from Mouse/Keyboard to PamOS to Phone
  • Easily customized via Applescript or perl or even just writing an app in C++, Java, C# (Mono)
  • Easily networked
  • Affordable

Ho hum. But my money is heavily invested in other hobbies already, so this one will have to wait until i can rationalize replace

  • in net
  • 1 min read

Gzip under .NET

The kind folks over at ICSharpCode have created a Zlib library with Gzip, Zip, Tar and Bzip2 implementations.

Tried it out last night and it works beautifully. It fits into the networking thread of last in that I've decided that for communication i'm going to use Gzipped Base64 encoded XML. That gives me a nice compact format that's quite portable. Already tried out sending a such encoded message from a perl program on Linux to .NET on Windows and it worked beautifully. And it's 90% smaller than plain old XML.

Maybe if the Fast Infoset Project takes off, there'll be a more compact binary XML. In the meantime, this approach is at least easy for anyone to read, what with the ubiquity of gzip and b64.

  • in net
  • 1 min read

Remoting and Mono

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.

  • in net
  • 1 min read

TCP communication

Played around with TcpListener and TcpClient a bit this weekend. Last time I did low level network programming was in perl and it's interface was basically a socket interface. I did multiplexing with Posix select to check on sockets that were ready to do some communication. With C# i decided to go the multi-threading route instead and use the slightly higher level interfaces TcpListener and TcpClient.

I use the listener in the main thread in non-blocking mode, using pending to decide whether to accept a new connection. Then i spawn a thread for each TcpClient and have it listen the the client.

So far so good and fairly simple stuff. Except that I can't figure out how to detect if a client closed the connection on me rather me disconnecting them. I thought i'd get a SocketException when the client goes away, but so far my experiments show TcpClient happuily trying to read from the socket forever. Ho hum.

Update: Ok, so i'm just blind. I was so wrapped up looking for exceptions telling me that the client went away that i ignored the normal method of checking whether the read call read 0 bytes, just like in normal Posix sockets. Now that works like a charm

  • in net
  • 1 min read

EndDTE vs. VCCodeModel

Trying to identify all the members in a class, i can use CodeElement.Kind and build a large case statement against vsCMCodeElement.. But once I hit vsCMElement.vsCMElementEvent I hit a dead end. All the others have CodeBlah interfaces I can use to get .Access from, but there is no CodeEvent.

Digging around the net for a while i found the Microsoft.VisualStudio.VCCodeModel namespace, which has VCCodeEvent which in turn doesn't have an .Access member. And anyhow how does this sucker relate?

It would be nice if there was a reference from the vsCMCodeElement enum to the appropriate CodeElement interface.

And while we're wishing, how about a C# to EnvDTE reference. Oh, well, more experimenting to come