Re: Poco-Server-IRC : Proposals for server to server protocol

[Matt S Trout]

On Fri, Nov 19, 2004 at 08:10:24PM +, Kidney Bingos wrote:
> Hey,
> 
> Just a bit of a ramble regarding the issues surrounding the implementation of 
> the server to server protocol in POE::Component::Server::IRC and a request 
> for comments.

> So what I am proposing is to "enhance" the server to server protocol in RFC 
> 2813 by including timestamps and numerics.
> 
> This would have the following impact:
> 
> - base poco-server-irc would only be able to link to other base 
> poco-server-irc
> - wouldn't be able to link to irc-2.10 ircds.
> 
> Thoughts? Comments? Rants? Flames?

Implement the standard. Then implement your improved version and provide an
option to turn it on.

Better still, see if there's some way to auto-negotiate using the improved
version if both ends are running poco-server-irc and fall back to the standard
version if not. That seems like it'd give you the best of both worlds.

-- 
Bring me my etherkiller; Oh clouds unfold! / Bring me the magic smoke of desire
I shall not cease from mental fight / Nor shall my LART rest in my hand
Till we have buried the bodies / Of all the lusers in all this land
  -- rpg, ASR[ My homepage is http://www.trout.me.uk/ ]

Poco-Server-IRC : Proposals for server to server protocol

[Kidney Bingos]

Hey,

Just a bit of a ramble regarding the issues surrounding the implementation of 
the server to server protocol in POE::Component::Server::IRC and a request for 
comments.

Background
~~

In writing poco-server-irc I have working to the IRC protocol as lay down in 
the RFCs 2810-2813. The only true implementation of these protocols as lay out 
in the RFCs is irc-2.10 , and this is the 
reference implementation I have been working towards with the component.

RFC 2813 - Internet Relay Chat: Server Protocol concerns the linking of IRC 
servers together to form a network. Two major problems that face an IRC network 
are: "net riding" where a user gains channel ops on a channel by riding a 
healing network; and race conditions with commands that affect users, such as 
KILL, MODE, etc. and those users changing NICK.

RFC 2813 and hence irc-2.10 deal with these issues in two ways: Channel/Nick 
delay; and Nick tracking.

Nicknames can get locked if:

* nickname is killed either by operator or collision.
* net has split and the nickname was lost in the split. 

Channels can get locked if:

* net has split, channel has lost channel operators in the split, and the 
channel becomes empty. The lock is triggered in the split, but it is activated 
only if the channel becomes empty. Rejoin of the net or expiring the delay 
timeout will release the lock again. 

Nick tracking is explained in RFC 2813 Section 5.6

TimeStamp protcol or TSora is used by Hybrid  and 
its clones and provides an effective mechanism against net riding and for 
fairer kills on nick collisions. It is assumed that Hybrid adopts a similar 
approach to nickname tracking.

ircu is a P10 protocol implementation. The P10 protocol uses timestamping like 
Hybrid, but also implements unique tokens for servers and clients. All 
communication between servers is conducted using these tokens, referred to as 
numerics. 

The Problem
~~~

I have nagging doubts about how to implement the server to server protocol for 
poco-server-irc. I'm troubled by the protocol as lay out in RFC 2813, mainly 
because I am not convinced that the mechanisms described are scalable.

I am not convinced that anyone would want to ever link this component to an IRC 
running irc-2.10.

So what I am proposing is to "enhance" the server to server protocol in RFC 
2813 by including timestamps and numerics.

This would have the following impact:

- base poco-server-irc would only be able to link to other base poco-server-irc
- wouldn't be able to link to irc-2.10 ircds.

Thoughts? Comments? Rants? Flames?

Let me know.

Thank you for listening.

=
Chris Williams
"BinGOs"
=
http://www.gumbynet.org.uk/
http://www.kidney-bingos.demon.co.uk/irc/
=


pgpdKP8GAKhCE.pgp
Description: PGP signature