Building an IRC Server 2

2021-04-20
2 min read

by Lucas

[join, rfc, storage, pass]

AAAAAAAAAAAAAAAAAAAAAH

During the second week, we started to search and work on the different functions related to channels, (JOIN, NAMES, MODE etc).

We started with JOIN command, and the first problem we encountered was “which RFC do we have to follow?”. So, between the ones we have to follow (1459, 2810, 2811, 2812, 1283, 7194), three of them mentioned JOIN.

So for your information:

  • rfc 2812 concerns clients request.
  • rfc 2813 server request.
  • rfc 1459 is an old version of 2812

As we don’t manage server connections for now, we focus on the rfc 2812.

When a client joins a channel we store a pointer to him in a vector of pointer to client in a Channel class. This attribute is public, because in private, modifying a vector isn’t very practical. This method gave us some problems in the following weeks, but for now it’s working fine.
(We used the same trick to store invite, channel operators etc.)

class Channel
{
	std::vector<Client*>		_operator;
	std::vector<Client*>		_users;
	std::vector<Client*>		_invite;
	std::vector<Client*>		_voice;
} //it has a lot of other attribute btw

While writing this post, I’ve read again the rfc and discovered that I forgot to handle the last argument of JOIN.
It’s used to quit all other channel where the client is.

Also if you want a functional server with different client, be attentive about the syntax like we said in the first post.
Don’t forget a whitespace in the answer or anything close to this. Some client like irssi are gentle and don’t mind those, while revolutionIRC will completly ignore your packet if it’s not well formated.
So don’t be afraid to use the proxy too much ;)

We finished a basic PASS command, the password is stored as a sha256 hash which is at the moment we are writting this a relatively secured cryptograophic hash function.

At the same time we discovered that on some client, while connecting to a server which already owns a nickname they want to use, they will send another nick AGAIN but without the USER command.
(e.g.: they don’t follow the rfc, because you shouldn’t be able to register with a nick command, but they are expecting it to work)
But anyway we handled that pretty easily, it’s was just a side note.

We also did PING & PONG (and pinging Client) not very hard to do and we started to work on PART.

That clears out the second week of work. Thanks for reading.