It’s been a while since I’ve written my last post.
Actually I was absent because in the meantime I’ve got a new job, I’m going to make some family’s changes (new house, new life), so all of my efforts were (and are) focused on doing my best in my new job, handle all the things that the life reserved to me, and yes, it’s been a quite hard find a moment to stop myself, thinking and writing.
Finally I’m here, trying to find some time to write a little post on things I love and I really hope it can be a rule for the next months.
Even though I love what I do day by day, there are few side projects I think they deserved to be told and yes, this post is about one of them.
To make a long story short, few months ago reading how the Redis development was going I was inspired by a new, old topic: the implementation of the gopher protocol.
It’s not a joke, and I know today gopher is not widely used anymore (HTTP rules), but I’ve seen in it an opportunity to learn a bit of history and why not, the opportunity to make a pure C implementation of a Gopher server to revive it’s RFC1436 and figure out how internet (the internet people know today) was at the very beginning, when the need was to empower people to publish and share information, getting rid of all it was related to the style and the cosmetic issues on presenting information to the end users.
Anyway, c_gopherd tries to be a tiny, minimal re-implementation of a gopher server and tries to make alive again that world in which you just had text based documents, hyperlink connections to other resources, experimenting a different way to do things.
If you want to have more context on this, I suggest reading few useful documents:

1. A bit of history around Gopher
2. The Gopher protocol in brief
3. Would you like to build your own Gopher{hole,space}?

The c_gopherd project

You can simply build it using the provided Makefile.
According to the defined $PREFIX, the default all target generates a bin/ directory containing the result of the compilation.
The config target is useful to generate a lib/defaults.h with all the user defined parameters.

$ make help

will show all the available targets.

$ make config

will generate the defaults.h according to the defaults.def.h

$ make

will compile and put the result in $(PREFIX) dir.

How can use it

$ ./c_gopherd -h
Usage ./bin/c_gopherd [-h host] [-p port] [-s srv_path] [-v]

More context on the project structure

In the /example project dir there is a little Gophermap file.
Customizing the GOPHER_ROOT directory (aka GROOT) or passing the -s path option, you can serve it as an HTML equivalent index.
In this way you can display your custom Gopher menu instead of just a directory listing.
A good approach enabled by the use of the gophermap is represented by the ability to create nested gopherholes indexed with their own gophermap in a structure like the following:

example/
  gophermap
  user1/
    gophermap
    user_1_content/
  user2
    gophermap
    user_2_content/
  content1/
  content2.txt
  ...
  ...

How the gophermap is built?

According to the RFC and the evolution of the protocol, the following table specifies the format and the content types allowed.
The technical specification for Gopher, RFC 1436, defines 14 item types. A one-character code indicates what kind of content the client should expect.
Item type 3 is an error code for exception handling. Gopher client authors improvised item types h (HTML), i (informational message), and s (sound file) after the publication of RFC 1436, and I think the informational message is very useful to organize better a gophermap and present the resources in a cleaner way.

An example of gophermap can be found here.

Conclusion

I really enjoyed writing the first version of this server and I hope I can continue soon implementing my todo list items, but one of the most important things is that this project has given me the opportunity to work again in C, learning about a very important piece of our history and share it with you.
So, have fun with Gopher, and welcome to port 70! :D