Author Topic: I4  (Read 12999 times)

Offline Tricky

  • BFF
  • ***
  • Posts: 189
  • I like what I code and I code what I like!
    • View Profile
Re: I4
« Reply #15 on: July 14, 2007, 08:02:49 AM »
The original router specs in the I3 protocol describes a decentralized topology but using a fully closed mesh (all routers connected to each other). I'm looking to set up a topology that uses an open mesh (each router only connected to one or more other routers). This should cut down on the amount of router to router traffic that is sent on broadcasts.

Tricky

Offline shadyman

  • Friend
  • **
  • Posts: 50
    • View Profile
Re: I4
« Reply #16 on: May 28, 2009, 10:13:13 PM »
Futureproofing.

Allow it to accept new "modules" like I3 does.

I know back with Zebedee mud, there was a big community built around making commands for the intermud. There were things like FTP, BBS, etc., all of which were not part of the original specification.

Offline Aidil

  • Friend
  • **
  • Posts: 50
    • View Profile
    • Way of the Force
Re: I4
« Reply #17 on: May 29, 2009, 04:07:52 PM »
This can be done without changing the i3 protocol for as far as muds are concerned, it can completely be solved by changes to the irn protocol and extending the 'network layout' bit of the current i3 spec.

While the current irn network is a fully connected network like the i3 spec suggests, the actual implementation esp. with regards to mudlist/channel data has little to do with the old i3 spec.
In the irn spec as it is used by *i4 etc (http://mud.wotf.org/i3/irn/v1/),  the current router a mud is connected to is said to be authoritive for that mud. This concept should be extended somewhat to allow groups of routers to share authentication data for a mud, and share responsibility for the data for that mud.

Beyond that, a seen-by array is needed in all irn packets, as is a packetid (router name + timestamp). ttl values need to be properly decreased and checked, and a route discovery protocol has to be defined.

But none of this has to affect i3 clients.

I believe some changes to the i3 protocol are desirable, but those mostly concern mudlist and chanlist synchronisation, adding channel descriptions (and possibly other properties) and allowing multiple destinations for a single packet.



Way of the Force

A Star Wars LPMud
wotf.org port 23

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: I4
« Reply #18 on: May 29, 2009, 06:19:14 PM »
Making the protocol plain-text, rather than the obscure mixture of LPC variable dumps + binary packet sizes, might go a ways towards making it simpler to implement, especially for non-LPC platforms.  Wouldn't it be nice to have ALL muds able to easily talk to one another?

Offline Aidil

  • Friend
  • **
  • Posts: 50
    • View Profile
    • Way of the Force
Re: I4
« Reply #19 on: May 29, 2009, 06:32:19 PM »
Supporting a plain text variation isn't very difficult (and pretty similar to what Cratylus is doing on the imc2 bridge)/

That said, the i3 protocol does somewhat take advantage of the fact that it uses mudmode and can transfer more structured data like mappings and arrays. You could do without mudmode for that, but would probably need something like xml, which imho isn't much of an improvement :)

Way of the Force

A Star Wars LPMud
wotf.org port 23

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #20 on: September 26, 2014, 08:17:07 PM »
Is anyone else working on this, I'm interested in starting on it myself

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #21 on: September 30, 2014, 04:40:12 PM »
Just Tossing up some ideas for the I4 protocol.

Im thinking about having all I4 servers exchange a list of known servers to connected muds and visa versa and weight them according to use so each mud can build a list of servers. so that if one I4 server is down they will automatically try the next one in the list until a successful connect is made

This would mean all i4 servers will talk to each other, and that anyone can run an i4 server and would not need to be authorised to do so. but servers will build a database of what mud is connected to which server so that traffic isnt seen by servers that dont need to see it for example:

Mud A is connected to Server2
Mud B is connected to Server 1
Mud C is connected to Server 3

Mud A sends a Tell/mail to Mud C, only server 2 and server 3 will see the data, server 1 will see nothing
but if mud as sends a message on a intermud channel lets say dchat, server 1,2 and 3 will see it

Also im thinking of building the I4 router to be standalone, C++ application that's open source
Also i was thinking of encrypting Private Communications?
 
« Last Edit: September 30, 2014, 04:48:46 PM by Adam@BlackDawn »

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: I4
« Reply #22 on: October 05, 2014, 05:57:23 PM »
Just to throw this out here...

I'm sure you guys noticed the recent I3 drama involving our friend Torak, and his attempts to destablize and bring down I3 by exploiting the fact that any MUD can allow anyone to chat over I3 channels.

How do you propose protecting the network from such activities if anyone can setup their own I4 router and automatically join in as an equal partner to everyone else?

Answer:  MUD's will form "cliques", and reject anyone outside their circle of trusted friends, and thus what used to be a unified network will dissolve into a bunch of fiefdoms, and newcomers will pretty much get to talk to each other.

A distributed network is a great solution when there are no trust issues to resolve, or when such things can be verified automatically.  Bit Torrent works well because the files all have a signature that can be checked, so injection of bad data is preventable.  In a chat network, "bad data" doesn't have such a signature.

With a central point of control, you are subject to that admin's idea of what is "fair", which may be annoying if you disagree.  With a distributed network, every single MUD will have to take on the task of playing whack-a-mole and blocking everything they find offensive or disruptive.

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #23 on: October 05, 2014, 07:57:06 PM »
Just to throw this out here...

I'm sure you guys noticed the recent I3 drama involving our friend Torak, and his attempts to destablize and bring down I3 by exploiting the fact that any MUD can allow anyone to chat over I3 channels.

How do you propose protecting the network from such activities if anyone can setup their own I4 router and automatically join in as an equal partner to everyone else?

Answer:  MUD's will form "cliques", and reject anyone outside their circle of trusted friends, and thus what used to be a unified network will dissolve into a bunch of fiefdoms, and newcomers will pretty much get to talk to each other.

A distributed network is a great solution when there are no trust issues to resolve, or when such things can be verified automatically.  Bit Torrent works well because the files all have a signature that can be checked, so injection of bad data is preventable.  In a chat network, "bad data" doesn't have such a signature.

With a central point of control, you are subject to that admin's idea of what is "fair", which may be annoying if you disagree.  With a distributed network, every single MUD will have to take on the task of playing whack-a-mole and blocking everything they find offensive or disruptive.

Hi Quixadhal,
I have not been aware of this recent problem i have not been around for sometime, i'd like to know more about that if you wouldn't mind giving me the run down in a PM as id like to know more.

I'm more then happy to keep the current centralised model of I3, but as you said people are injecting bad data perhaps I4 should have the ability to automatically  resolve such issues by verifying that data send via muds to other muds is legitimate traffic, I understand it would not be a simple task but I think from a technical point of view it could be done, depending on the exploit being used but at this point my knowledge is lacking unless you can fill me in, I can only speculate.

If we were going with a centralised model: when its live i'd suggest using one dns host with 3 different IPs for example i4.themud.org or i4.lpmuds.net or some domain

1. point to my server
2. pointing to crats server (if he is willing to run a i4 server, i have not asked)
3. another 3rd party

only so people do not need to know IP's and the servers can change IP addresses with out clients needing to be updated, also helps with load balancing and appropriate selection of IPv4 or IPv6.

As for the rules of the network and keeping things fair, I'm happy with the job that's been done so far from my experience things have come along way since the original i3 network. I'd like for crat to continue administering the proposed i4 network
« Last Edit: October 05, 2014, 08:01:10 PM by Adam@BlackDawn »

Offline Newt

  • Pottymouth
  • *
  • Posts: 19
    • View Profile
Re: I4
« Reply #24 on: October 06, 2014, 02:58:59 AM »
I'm sure you guys noticed the recent I3 drama involving our friend Torak, and his attempts to destablize and bring down I3 by exploiting the fact that any MUD can allow anyone to chat over I3 channels.

How do you propose protecting the network from such activities if anyone can setup their own I4 router and automatically join in as an equal partner to everyone else?

The structure of the network is moot.  As long as you keep it easy to join the network (as it should be) then the Toraks can just grab another IP and be right back in business.  The way I3 does it with channel owners being their own authority and mud's being held accountable for their people is about as good as it gets.
« Last Edit: October 06, 2014, 03:02:38 AM by Newt »

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #25 on: October 06, 2014, 04:04:38 AM »
well I'm currently waiting for a HP tech to come to my house to fix my laptop... mobo shat it self, once they fix it i'll start writing up the new specs and start designing the new protocols. I can always change the network design a little later

On a side note: the original design of I3 was always to be an open network with no real enforceable rules, and responsibility always fell on the muds it self.

However saying that Muds hosting their own channel I may possibly design it to allow them to make them public or private and allow them to ban offensive muds from their channel (private = by invite, public = anyone can join).. simply just throwing some ideas around nothing is definite feature wise at this stage as its a bit early

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1020
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: I4
« Reply #26 on: October 06, 2014, 08:12:27 AM »
It's hard to respond to this without giving bad guys good ideas, so I'll keep it vague.

The observation that the protocol started out being open is valid. However, remember the times. Not everyone had the skill, resources, and platform for running a mud. It is now trivial to run a mud from mobile platforms behind varying levels of source obfuscation. The casual approach of dealing with griefers in 1996 manifestly no longer works.

For now this means you need an admin or two that pay attention and responds to threats. Probably this is a weakness in the long term.

One alternative is to develop a network that works on a community consensus as to who is good and who is bad, and has points of trust from which blacklist and whitelists can conveniently be shared, and....and this is the important part....and a protocol whose implementation can be conveniently updated and distributed as new ways of undermining the community arise.

This is a pretty tall order for a community trundling along mostly on momentum. I think we're probably better off having a few trusted community figures run peer i3 nodes, and clean up the Inter Router Networking protocol.

I certainly like the idea of a distributed network: it's less work for me. I just happen to have seen it work poorly (i2) and I think it needs not only a critical mass but also a minimum adoption rate and a very robust maintainership cadre for it to be something other than a pet coding project.

No fense, sorry if this sounds like rain on the parade, and anyway, I hope I'm wrong so dudes like you know who aren't my problem :)

-Crat

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #27 on: October 09, 2014, 08:25:47 PM »
Is it just me or are there posts missing? and some topics...
like MudOS Mirror @ http://lpmuds.net/smf/index.php?topic=1566.0

DAFUQ?!?!
« Last Edit: October 09, 2014, 08:30:48 PM by Adam@BlackDawn »

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1020
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: I4
« Reply #28 on: October 10, 2014, 02:00:14 AM »
IIRC I wanted to set the forum not to allow people to delete their posts and threads, but when I looked, it wasn't convenient to do with this software.

Maybe things have changed since then, I'll look into it.

-Crat

Offline Adam

  • Global Moderator
  • *****
  • Posts: 33
    • View Profile
    • TheMud.ORG
Re: I4
« Reply #29 on: October 10, 2014, 02:58:13 AM »
IIRC I wanted to set the forum not to allow people to delete their posts and threads, but when I looked, it wasn't convenient to do with this software.

Maybe things have changed since then, I'll look into it.

-Crat

Well the thread i mentioned was started by me and i didn't delete it, its seems as tho lpmuds.net has just gone back in time a couple of days