2

RFC 2810 says the following about one-to-one communication:

Communication on a one-to-one basis is usually performed by clients,
since most server-server traffic is not a result of servers talking
only to each other. To provide a means for clients to talk to each
other, it is REQUIRED that all servers be able to send a message in
exactly one direction along the spanning tree in order to reach any
client. Thus the path of a message being delivered is the shortest
path between any two points on the spanning tree.

(Emphasis mine.)

What does this "one direction" mean? To only one client? And how does this "reach any client" and find "the shortest path between any two points [hosts on the IRC network]"?
And why not simply cut the crap and store IP addresses of clients and let IP do its job? After all, IRC is built on top of TCP/IP.

Community
  • 1
  • 1
cadaniluk
  • 15,027
  • 2
  • 39
  • 67

2 Answers2

5

Johannes alludes to the solution but doesn't fully answer your questions. He is however correct in that graph theory is a large part of the answer.

Because each child node in server maps of EFnet and IRCnet have only one parent, the shortest path is the only path between two servers on the graph; the same vertice cannot be visited twice without backtracking. This is called a spanning tree, where all nodes are connected, but no loops exist.

IRC is not necessarily unicast like TCP/IP. It communicates with multiple clients on different servers by broadcasting. The important thing to note is that the Client says 'send 'hi' to everyone on #coding', and the message travels from the client to the connected server. That server passes the message to any connected servers, and those servers pass it on to any clients subscribed to #coding and then on to any connected servers.

There isn't really anything like 'client-to-client' communication; one-to-one is accomplished by sending a message to a user with the specified name; not ip address. NickServs help to prevent people from hijacking names, and temporarily associate a nickname with an IP, refusing to authenticate other IP addresses, and protecting the nickname with a password when authentication expires.

In much the same way as sending a channel message, the user sends a message to the server 'send 'hi' to @nicky', and the server simply passes this message on until the client @nicky is listed as a client connected to the server receiving the message. Bots provide a means for @nicky to receive messages when offline; they sign in under the username. EDIT: IRC actually opens an invite-only personal channel for client-client communications.

Essentially, the shortest path guarantee is a result of IRCs broadcast policy; the moment a message propagates near the desired user's server, it is forwarded to the desired user. Timestamps presumably prevent echoed messages if there are loops in the graph of servers.

In the architecture section, we find evidence that 'spanning tree' is being used in the proper sense. Servers are aware of eachother so as to prevent loops (guarantee shortest paths) and connect efficiently:

6.1 Scalability

It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers, clients and channels and that information regarding them be updated as soon as it changes.

and this one below is a result of having no alternate paths/detours to take

6.3 Network Congestion

Another problem related to the scalability and reliability issues, as well as the spanning tree architecture, is that the protocol and architecture for IRC are extremely vulnerable to network congestions.

IRC networks are designed to be IP agnostic, and follow the shortest path because messages propagate the whole graph, stopping when they reach an endpoint. Clients and servers have enough information to discard duplicate broadcasts. IRC is a very simple, but effective chatting protocol that makes no assumptions about security, IP, or hardware. You could literally use a networked telegraph machine to connect to IRC.

Aaron3468
  • 1,734
  • 16
  • 29
  • 2
    IRC's server-to-server protocol rejects connections from servers already introduced to the network,as well as from servers that attempt to reintroduce a server already connected, thus blocking loops This has also been used from time to time in an emergency - because the server name (or SID in some protocol variations) is a key that must be globally unique, a misbehaving server may be locked out of the network by bringing on a placeholder server to occupy it's name, thus insuring any link that would introduce that server to the net fails - a technique referred to as "juping" the server. – Stephanie Jul 24 '16 at 07:10
  • 1
    Also worth noting, IRC's spanning tree protocol doesn't guarantee the shortest possible path, it guarantee's the shortest possible path over the links currently established. Those links can be arranged in a way that is not optimal - for example, links can be established that go from North America to Europe and back, This creates a management challenge, as operators must decide whether it's better to split and reestablish links in a more logical arrangement, thus temporarily disrupting users, or leave the situation alone, thus slowing down the network. – Stephanie Jul 24 '16 at 07:14
  • @Stephanie That is a good observation, though in that case I would reserve the word 'short' for algorithmic distance, 'optimal' for efficiency, and 'local' for real world distances. – Aaron3468 Jul 24 '16 at 07:17
  • You can also end up with links that are suboptimal in that regard as well - nothing about the protocol stops you from creating longer chains than necessary (and this frequently happens when a provider operates both a dedicated "hub" and a leaf server - their hub may at times only serve to connect their "leaf" to the rest of the network, while their leaf will only connect to *their* hub, adding an extra hop to the network paths) – Stephanie Jul 24 '16 at 07:38
2

Every IRC server is connected to one or more servers in the same Network. A client connects to one of the server. Let's suppose we have the following setup:

    A    
   / \
  B   C
 /   / \
D   E   F

Let's suppose a client on server A wants to send a message to a user on server E. In that case, server A only sends a message to server C, which will send this message to server E, but not to F.

If a client on A sends a message to a channel with users on the servers B and E then A will send the message to the servers B and C. B will send the message to the users in that channel that are connected to B, C will send the message to server E, which will send the message to it's clients in that channel.

Server D and F will never see the message because nobody in that channel is connected to them, but C will see the message even if nobody in that channel is connected to C because it has to rely the message to E

Johannes Kuhn
  • 14,778
  • 4
  • 49
  • 73
  • So "one direction" just means Unicast? But still, why reinvent the wheel when IP provides you with this very Unicast mechanism? And how is what you described causal to always finding "the shortest path"? – cadaniluk May 06 '16 at 14:47
  • 1
    When dealing with messages sent to channels, It's effectively multicast over unicast links - the servers pass a single copy of the message in each direction that has users "listening" by being on the channel, and each of those servers relay the message to their directly connected clients on that channel. This makes IRC very efficient over links that might have bottlenecks or high costs, such as transoceanic or satellite links - as only one copy of message that may be intended for hundreds or thousands of users on the other side of the world has to traverse the constrained part of the net. – Stephanie Jul 24 '16 at 07:33