Re: Mesh linking - technical (Was: Re: [Unreal-users] Planned features for 3.3?)

[tabris <ta...@ta...>]

On Monday 20 June 2005 8:12 am, Saturn, the bringer of old age wrote:
> On Sun, 2005-06-19 at 17:01 -0400, tabris wrote:
> > On Sunday 19 June 2005 11:02 am, Bram Matthys (Syzop) wrote:
> > > Basically the problem is sequencing and difference in lag.
> > > Example:
> > > - a mesh network ABC where all nodes are connected to each other.
> > > - A<->B has 0.1s of lag
> > > - A<->C has 0.5s of lag.
> > > - B<->C has 0.1s of lag (irrelevant in this example)
> > >
> > > [SERVER A] User a connects to this server and joins #chan
> > > [SERVER B] Got this message from server A, a user on this server
> > > sends a 'MODE #chan +v a' (say, an autovoice bot).
> > > [SERVER C] Server C still hasn't received the message from A yet,
> > > but does get the 'MODE #chan +v a', however 'a' does not exist,
> > > hence this mode is ignored.
> > > [SERVER C] Server C gets the connect+join message from server A.
>
> There are a couple ways to deal with this, one off the top of my head
> is: each server has its own sequence number that gets incremented
> every time it sends a line. Then when something that depends on
> previous state happens it refers to this number. So you get something
> like:
	This part is at least somewhat familiar from what I remember of the=20
freenode conversation. timestamp + sequence. which isn't that different=20
from UUID, except the sequencer certainly does a better job of=20
serializing operations. No doubt it could be combined if necessary.

	I think at some point it becomes obvious that although we might wish to=20
preserve the 510 char limit on client protocol, we will be forced to=20
abandon it for server-mode. and given optimal packet size now is=20
1492-1536 (depending on transports), I figure it wouldn't hurt us to=20
allow a ~1024 cmdlen for server protocol. This would then allow more=20
semantic information to be passed per cmd.

	On a somewhat unrelated note, is there any reason that NICKIP's base64=20
(which uses the standard table) has to use a different table from IRC=20
base64 table?

>
> Server A user connects then joins the channel on line number 500
> Server B sends the mode command with its own line number but also
> refers back to line number 500 from server A
> Server C stores the mode command until it receives line number 500
>   from server A, then processes it.
>
> Please CC me as I'm not subscribed to the list.

=2D-=20
Kids have *never* taken guidance from their parents.  If you could=20
travel back in time and observe the original primate family in the=20
original tree, you would see the primate parents yelling at the primate=20
teenager for sitting around and sulking all day instead of hunting for=20
grubs and berries like dad primate.  Then you'd see the primate=20
teenager stomp up to his branch and slam the leaves.
		-- Dave Barry, "Kids Today: They Don't Know Dum Diddly Do"