During the last few weeks I've been going over various parts of the channel model and giving some commentary about using those classes. Looking back at the list of topics, we've already covered everything you need to build a custom transport. Today I'm starting a series that ties everything together by going step-by-step through building a custom transport over a file protocol.
Here are the basics of the protocol. We're creating a new scheme called "my.file" that ignores the hostname and port and just uses the path of the URI. The path indicates a directory on the file system that we'll use to exchange messages. The transport will expose a request-reply interface. The request channel writes its message to a file in the directory called "request". The reply channel then reads the message and writes its response message to a file in the same directory called "reply". You can use any encoding you want with this protocol, but there is no default encoding.
To keep the example simple, I've cut a few features out of the transport. You won't want to use this transport in a production system!
I'm not going to call out specific past articles most of the time during this series. Almost everything has been talked about at one point in time if you look at the archive. Here's a master list of classes that get extended by the sample. You'll have to follow the links in the articles to get to parent classes and interfaces where applicable.
There's actually a total of ten classes in the sample. The two classes that don't appear in the above list are the client and server.
Next time: Building a Custom File Transport, Part 2: Server