unreal-users

[Unreal-users] Unreal IRC without DNS

[<Mic...@iz...>]

Hello @ all!

I want to run Unreal IRC in a LAN without Internet. There is no DNS-Server
in this LAN. When i connect to the IRC-Server, it takes about 30 seconds
till my nick will be accepted by the server. I think in this time the server
is locking for my DNS-Name. How can i solf this problem?

Thanks for help!

---------------------------
Sorry for all the grammar mistakes, I'm a english nerd ;)

Re: [Unreal-users] my Unreal 3.2.3!

[Christian 'H. M. <ad...@in...>]

Typo,

i mean two / three month you are a good Admin :)

2/3 hours is impossible :)

HERZ


Christian 'HERZ' Makowski wrote:

> and maybe two / three hours you are a Good IRCD Serveradmin.
>

Re: [Unreal-users] my Unreal 3.2.3!

[Marcus J. <new...@on...>]

Read example.conf, and the documentation,

that explains all aspects of the unrealircd.conf and any other
.conf usualy has VERY good documentation written into it.

Pierce

minmoehtet naing wrote:

>Dear Everone.
>Firstly i am new to this group.
>And i am true newbie running Unreal the very first time in my life!
>i now installed ircd Unreal 3.2.3 Server on Windows 2003 server and
>now is running " just only" normally. No more.
>I can join and chat from my irc clients and it is OK.
>But u know i want my Unreal server running productively, more properly
>and beautiful with feature-rich configurations.
>As u have already known i am first to this.
>so i don't know how to configure all ".confs" files to be
>productive,proper and good funuction.
>What i want to request u all is,  i want already configured .confs
>files as examples for my study and configurations.I want them all to
>be sent as attachments to me.
>my Unreal server ip address is 192.168.200.12, host name is iserver.svplus.biz.
>i used a proxy server for internet connection,this server add is
>192.168.200.1,host name is server1.
>so plz,guide me,educate me,how to configure further with your example
>.conf files for me.
> i intend my unreal server to run locally for my students .
>plz,help us.
>we truly need your assit.
>with respect.
>
>
>
>
>
>  
>

Re: [Unreal-users] my Unreal 3.2.3!

[Christian 'H. M. <ad...@in...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi,

Trying and testing are the best Metode to Learn and Understand
UnrealIRCD. Copy / Paste from other unrealircd.conf is not good.

The Trick is:
Learning by doing, Every Day some hours... and maybe
two / three hours you are a Good IRCD Serveradmin.

I recommend to read this Side:
http://www.vulnscan.org/UnrealIrcd/unreal32docs.html

This is the best Way to Learn!

Regards
HERZ
- ---------------------------------------
Networkadmin / Unreal Support Team



minmoehtet naing schrieb:

> Dear Everone. Firstly i am new to this group.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
 
iD8DBQFCuopUpL5SuZ0flhIRAqOuAKCDNtlmULZxGdiRoqHr5UCWPdGkowCgjVyh
cZhbXXv/ZS87jq9SLkbY42U=
=9GWI
-----END PGP SIGNATURE-----

[Unreal-users] my Unreal 3.2.3!

[minmoehtet n. <min...@gm...>]

Dear Everone.
Firstly i am new to this group.
And i am true newbie running Unreal the very first time in my life!
i now installed ircd Unreal 3.2.3 Server on Windows 2003 server and
now is running " just only" normally. No more.
I can join and chat from my irc clients and it is OK.
But u know i want my Unreal server running productively, more properly
and beautiful with feature-rich configurations.
As u have already known i am first to this.
so i don't know how to configure all ".confs" files to be
productive,proper and good funuction.
What i want to request u all is,  i want already configured .confs
files as examples for my study and configurations.I want them all to
be sent as attachments to me.
my Unreal server ip address is 192.168.200.12, host name is iserver.svplus.=
biz.
i used a proxy server for internet connection,this server add is
192.168.200.1,host name is server1.
so plz,guide me,educate me,how to configure further with your example
.conf files for me.
 i intend my unreal server to run locally for my students .
plz,help us.
we truly need your assit.
with respect.





--=20
thetnaing@minmoehtetnaing
MATRIX-iEXCELLENT
NetworkElite

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"

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

[Trocotronic <tro...@ra...>]

Hi,

So, what will happen with PRIVMSG?
Imagine this schema:

A -- B
|        |
C -- D

User 1 ison A, and user 2 ison D. User1 queries to user2. Which server must 
send the message? Which way A have to choose? Through C or through B? Both?

Instead using line numbers and storing amount of data, servers could use 
"ghost users". In Syzop's case, server C introduce a "ghost user" with 
"nodata" as an ident, ip, realname, etc. and mark him as a ghost too. So, 
users on C will see
"Trocotronic!nodata@nodata JOIN #chan
userB MODE #chan +v Trocotronic"
When server C will receive USER command from A, it will store new data and 
will send a part/join into #chan to users on C (as /mode +x and 
set::allow-userhost-change is set to force-rejoin, I remember) and users on 
C will see
"Trocotronic!nodata@nodata PART #chan
Trocotronic!myident@myhost JOIN #chan
serverC MODE #chan +v Trocotronic"

Idem for KICK, PART and so on.

Trocotronic.
-------------------
"I think TV is very educational. Everytime someone turns on, I go to another 
room to read a book." Groucho Marx

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

[Bram M. (Syzop) <sy...@vu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

christian sullivan wrote:
> Just to cast my .02 into the ring..here are my thoughts.
> 
> There is just really no way that you can (sanely) do full mesh All:All
> linking on larger networks.
> That said, here are some of my thoughts on the idea.
> 
> In order to handle desynch issues, a simple syn/ack type system could
> be implemented.
> 
> User on Server A sets mode +i
> Server A sends mode change to Servers B and C
> Server B acks, Server C does not
> Server A tries n more times to update Server C
> (now let's just get silly...)

If it's TCP then it doesn't make much sense to try multiple times,
unless you actually reconnect of course :).
(But.. it doesn't have to be TCP per se, especially if you put in
sequencing numbers and all that stuff, it makes more sense to go the UDP
way)

But.. I'm not sure if what you said is related to the problem I stated,
since acknowledgments as-is don't solve that particular problem :(

> When a server joins the "mesh" it sends a ping type request, and based
> on the latency/response time of the ping-replys it assigns each server
> in the mesh it's own internal metric

That makes sense (especially for non-full-meshing), but also doesn't
solve the problem from above, since lag will vary from time to time.

On a side note, as others mentioned, you probably also want the option
to humanly control this.

Of course, there are many docs on this subject because routers have been
doing this for a long time.

tabris wrote:
> 	This issue came up on #freenode a year or so ago, and although nothing 
> was really resolved, among the ideas that came up was multi-path 
> routing combined with unique IDs. So you'd have something like a UUID 
> (which usually contains a timestamp too).

This too, doesn't seem to solve the problem. As you can see in my
timestamp idea it's not a good solution because you would have to
artificially introduce a sticky lag of X seconds, and if the lag would
be >X you would have a (non fatal or not) split.
Since, if you process messages realtime you cannot say later on "oh
oops, actually message Y should be before the message X I just sent
out". Too bad IRC servers do not yet have timemachine capabilities ;).

Saturn, the bringer of old age wrote:
> 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:
> 
> 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.

This one is particularly interesting, it seems to (try to) handle one of
the source problems which is dependencies.
At first, it seems to theoretically at least solve the JOIN+MODE and
JOIN+KICK problems. In practice it seems a bit more complex of course,
like we would have to store seq# of all joins (easy), and at least
MODE's can have multiple dependencies (:a JOIN, :b JOIN, :x MODE +vvv a
b c) [also easy, I guess].

Of course, there will still be odd issues, such as:
<Bot> -Blah-: <some nice infoline here>
*** Blah joins #blah
*** Bot sets mode: +o Blah
But ah well.

*think a bit further out loud* :)
how about a JOIN, MODE, PART (or JOIN+MODE+QUIT, even).
I suppose in that case we could just use message sequencing without any
dependency stuff (for PART/QUIT).
Let's have some sequencing fun (a different problem, I know).

Let's take this network setup:
  B----C
 /|    |\
A |    | F
 \|    |/
  D----E

{actually B<->E and D<->C might also be connected}

A and F are "leafs", B/C/D/E are routing servers ("hubs"). Naturally in
a real network setup there would be many more leafs, but ah well.

Now, whenever for example a broadcast message from A->ALL travels the
net, and the shortest path to C would be A->B->C (it is at least in # of
hops)... Now suppose B dies... C still needs to get the message.
So who is gonna save that message until it gets "acknowledged"? The
directly connected servers is not a good idea (B, in our case), since
they might (will) die... So I suppose we would have to revert to the
source server, in this case A, to keep a copy. Of course this is
sub-optimal, since "client servers" should theoretically deal as few as
possible with all this routing stuff etc, but it's the only way to - for
example - guarantee delivery of non-broadcast messages such as private
messages.
Then, server A will have to resend the message to C (this time via
A->D->E->C.
Ok, that all makes sense to me...

I'm wondering what would happen if we had for example, from the bot
points of view (which, will be on server D):
:master JOIN #chan {message #100}
:MODE #chan +omi master {message #101}
Now what happens if the JOIN gets delivered from A->D, but then the
server dies when it wants to send it A->B.
The bot will see the join, and do the MODE.
The MODE will be broadcasted from D->B, D->E, etc.
So B will see the mode but it will have a dependency on {message #100}.
Unfortunately, at this moment the server A just died, so server B will
never receive this message, nor can it request A to resend.
Now, we have the situation where we have this MODE in the queue... but
what are we going to do with it?
We cannot simply throw it away because the MODE also did an +mi. We
could of course, still process it, but then the '+o master' should not
be done.
Now, we could have a nice problem with 'master' being joined from
another server, but NICK(U)ID can solve that problem (which is on TODO
btw, but not because of meshing).
Not sure if I missed anything in the above story that could still lead
to any problems?

Oh yes, I did: what if server A's network gets extremely lagged (and
will ultimately have all their links timed out)... Would the MODE +omi
master (or more specific, the +mi part) be delayed up to <server link
timeout> seconds? Obviously that would be no good.
For a tad more realistic scenario one could imagine it being a +ol 20 (a
+o for the known user, combined with the +l 20 by the classical "set
limit to <numusers>+<somevalue> script"), but actually the +omi isn't
all that uncommon either, for smart eggdrops that is :).
For some reason, I doubt it would be acceptable to have a +mi (or any
other non-directly-user-affecting mode, including +be) mode delayed for
like 30/60/90/120 seconds.
Of course, you could set this time limit to a low value like 15s, but
wouldn't we then end up with (much) more splits than without meshing?
And still, delaying a +i for 15 seconds will be quite desasterous in
most cases.

Another, more likely scenario, is a multi-user-KICK. At the moment we
don't have that at Unreal, but it might be implemented some day.
In that particular case, the KICK for all those persons would have to be
delayed until all persons joins have been received.
Unless you go "split down" such kicks in individual ones.. Perhaps you
could even do the same with modes... although that must be quite an
insane idea/funny view.
In that case ':Bot MODE #chan +omi master' will be translated to a '+mi'
and a '+o master', giving 2 mode lines... That must be real fun with
like 6 arguments.. all those +o's on a different line. Actually, I've
seen that plenty of times on M$ Exchange IRC servers, it's just.. ugly.

Thanks to everyone that contributed so far, it's nice to see some real
technical discussion on this subject[1] :).

	Syzop.

[1] The reason I originally did not post it on searchirc is because
    I expected a lot of idiots replying with their "I thought about
    this problem for 10 seconds and I know the solution!" replies.

- --
Bram Matthys
Software developer/IT consultant        sy...@vu...
PGP key:                       www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D  1811 E1C3 D65F E6ED 2AA2

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCttXz4cPWX+btKqIRApSlAJ4z/jeFmWv/004AFY8tHxjiPAwWSgCg1NXa
+CayVFK5bPyhnV3XsLhGIYM=
=DLLv
-----END PGP SIGNATURE-----

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

[christian s. <han...@gm...>]

Just to cast my .02 into the ring..here are my thoughts.

There is just really no way that you can (sanely) do full mesh All:All
linking on larger networks.
That said, here are some of my thoughts on the idea.

In order to handle desynch issues, a simple syn/ack type system could
be implemented.

User on Server A sets mode +i
Server A sends mode change to Servers B and C
Server B acks, Server C does not
Server A tries n more times to update Server C
(now let's just get silly...)
Server A passes a flag around the mesh claiming Server C is unreachable
Other servers in mesh try a test syn/ack, No response from Server C!
Servers Auto-Jupe Server C and an event is logged/triggered

That's at least one way it could be done (the Jupeing is a bit silly
really). Another idea I could see scaling a little better is this:
When a server joins the "mesh" it sends a ping type request, and based
on the latency/response time of the ping-replys it assigns each server
in the mesh it's own internal metric. Any server over a certain metric
is dropped from it's internal table of "Servers to send updates to".

The idea being that rathers than sending updates to *every* server, we
will instead send updates to every *close* (in terms of speed, not
physical location, obviously) Server. The nice thing about this is
that we could hard assign a metric. For example, we have a server in
NY and a server in LA, we realize that there are times when these two
servers may not respond fast enough for the cut, but we also know that
these are both high traffic primary servers on our network, so we hard
code a low metric so that updates are always sent from to the other,
and to help eliminate desync, we also use the syn/ack system (sans
silly jupe idea).

--=20
Christian Sullivan

One Pill Makes You Larger,
and one pill makes you small.

http://freezerpants.com ||  http://superimposable.org

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

[Saturn, t. b. of o. a. <sa...@su...>]

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.=20
> > [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:

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.

Re: [Unreal-users] Planned features for 3.3?

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

On Sunday 19 June 2005 11:29 am, Bram Matthys (Syzop) wrote:
> tabris wrote:
> > 	What is the planned feature list for 3.3? The FAQ doesn't list it,
> > and there's nothing in google either.
>
> Yeah, I've though about publishing it, but.. I also don't want to put
> all kinds of ideas online that others can "grab" before we actually
> implemented it ;). Another reason is I (we?) don't want to expect
> everyone to have feature X implemented that is on the list. Some
> things might not be done.
	An idea that I'd like to see:
1) client-level zlib compression. I admit it would chew CPU, but it=20
doesn't have to be over level 6 to be effective. many would just go for=20
level 3 or so.
I also realize that it would require client-support, and that many=20
client authors do not give a damn.
2) More flexible per-channel message filtering. chmode +G isn't that=20
effective, and kick-for-swear scripts are rather pointless. By the time=20
someone has sweared, it's too late.
>
> In any case, among them are:
> - Completely different I/O engine, one that deals with
> kqueue/epoll/etc. While tests show that the performance advantage
> isn't as big as one would expect, it will be cleaner code (which
> means less bugs, easier to extend, etc.). - Besides the above,
> several other subsystems will be completely replaced and/or
> rewritten. Others will be highly improved (speed). Basically in all
> cases it would result in cleaner code, and lower cpu usage.
> - Much more will be modulized. This is especially for "hot swap"
> ("hotfix") purposes (patch the ircd for a vulnerability or normal
> bug, without requiring a restart).
> - Numerous new features (web interface, distributed spamfilter,
> internationalization of numerics/messages, and more)
Web interface I'm ambivalent on. I have too much problems with idiotic=20
admins already, this will just lower the bar and allow in new levels of=20
idiots.
Distributed spamfilter. what's that? we already have them in the files,=20
and we have them in TKL F.
I18N sounds good, tho I think at some point we might need to discuss a=20
new client-protocol for this. Unicode anyone?
> - Some of these things might be discussed on the forums to gather
> opinions (such as more customized oper levels, etc.)
Point. I just wish it would happen more on the ML. The web is good. it's=20
just not so good for many-to-many communication.
>
> The main goals (in this order) for 3.3* are:
> - Cleaner code
> - Speedup
> - New features
>
> So yes, new features isn't #1. Still, there will be many (major) new
> features of course ;). It's just that we will concentrate much more
> than usual on cleaning up the code and optimizing things, which is a
> good idea IMHO.
>
> > With 18 months to do the development, anything is possible, right?
>
> One would say so.
> Still, it depends on how many "anythings" there must be done.. ;).
>
> 	Syzop.

=2D-=20
Colvard's Logical Premises:
	All probabilities are 50%.
	Either a thing will happen or it won't.

Colvard's Unconscionable Commentary:
	This is especially true when dealing with someone you're attracted to.

Grelb's Commentary:
	Likelihoods, however, are 90% against you.

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

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

On Sunday 19 June 2005 11:02 am, Bram Matthys (Syzop) wrote:
> {note to anyone who is planning to reply: please read the whole text
> first}
>
> tabris wrote:
> > 	What is the planned feature list for 3.3? The FAQ doesn't list it,
> > and there's nothing in google either.
> >
> > 	One thing that comes to mind is mesh routing. So far one
> > experimental IRCd has it, maybe it should be possible to stick into
> > Unreal. With 18 months to do the development, anything is possible,
> > right?
>
> This is a (searchirc) forum post I prepared a few months ago but
> never send out:
>
> Mesh linking (without desynchs) impossible?
>
> Just like many other ircd coders I have been thinking of alternative
> linking methods for a long time, several years ago I've also written
> a simple ircd once that implemented mesh linking (eg: in all-to-all
> principle). But I've always been wondering if mesh linking is really
> possible without desynch issues.
>
> 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.=20
> [SERVER C] Server C gets the connect+join message from server A.
>
> The desynch is clear, user 'a' is voiced on server A and B, but
> voiceless on server C.
>
> {note that the above example occurs due to JOIN+MODE, it is not
> required nor relevant that the user just connected. Naturally there
> are several other occurrences of this problem, such as JOIN+KICK,
> etc, but this particular JOIN+MODE one is the hardest to solve, so
> let's concentrate on that one}
>
> With normal IRC linking this situation is not possible.
>
> So while I agree it's not hard to simply code something that connects
> all-to-all (or even with servers connected to 1 node), it's much
> harder - if not "impossible" - to prevent any desynchs.
>
> Alternate methods (I think they also appeared in IRC3), including
> "resend" systems with acknowledgments etc, can AFAICT also not deal
> with this problem.
>
> One possible crazy way I can think of to deal with this problem is to
> have absolute time, basically delay all actions several seconds (or
> whatever <max acceptable lag> is), order them by absolute time and
> then execute them (for example MODE=3Dt110, CONNECT=3Dt000, JOIN=3Dt020).
> Something I highly doubt anyone would want (besides you never know
> how much you should actually delay, so it's completely infeasible
> anyway).

	This issue came up on #freenode a year or so ago, and although nothing=20
was really resolved, among the ideas that came up was multi-path=20
routing combined with unique IDs. So you'd have something like a UUID=20
(which usually contains a timestamp too). I agree on the 'taking more=20
bandwidth'. And after looking at some of the docs on InspIRCd, I've=20
felt like asking if they have _any_ clue on real network-theory.

	If nothing else, full meshing is pointless b/c some servers may not be=20
reachable even under optimum conditions (certain kinds of hubs, or IPv6=20
vs IPv4). Further, full meshing is inefficient. It would be better to=20
have leaves have multiple hubs, and hubs to be doubly or triply linked.=20
But not to have N:N linking (exponential/factorial complexity,=20
anyone?).

	Of course, there is also the fact that full-meshing ignores the fact=20
that there are certain routes that are more efficient than others, and=20
that it should be the humans job (or at least option) of choosing those=20
routes.
>
> There is also another "possibility" as well, which is if all servers
> forward all (broadcast related) stuff they receive one time... so
> even though a broadcast message will go A->B and A->C, you could also
> let it forward by B too, so A->B->C AND A->C. In that case this
> sequencing problem disappears. Downside is that you are using XX(X?)
> times more bandwidth than needed on an average network (if I'm not
> mistaken the formula is SERVERS*(SERVERS-1) ?), which I doubt is
> acceptable.
>
> I wonder if the coders of the few ircds that implemented mesh links
> actually thought of things like this (brain?), because I have a
> feeling they simple implemented it (like I did several years ago, and
> yes, it was fun) instead of actually thinking trough all these
> possible (theoretical) desynch situations and how to deal with them.
>
> Any (well-thought-through) comments are welcome. I would love it if
> someone could prove me wrong and resolve these issues by some things
> I haven't thought of yet. That would mean mesh linking is more viable
> than I thought, but - for now - I'm afraid I'm correct.
>
> 	Syzop.

=2D-=20
Keep ancient lands, your storied pomp! cries she
With silent lips.  Give me your tired, your poor,
Your huddled masses yearning to breathe free,
The wretched refuse of your teeming shore.
Send these, the homeless, tempest-tossed to me...
		-- Emma Lazarus, "The New Colossus"

Re: [Unreal-users] Planned features for 3.3?

[Bram M. (Syzop) <sy...@vu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tabris wrote:
> 	What is the planned feature list for 3.3? The FAQ doesn't list it, and 
> there's nothing in google either.

Yeah, I've though about publishing it, but.. I also don't want to put all kinds
of ideas online that others can "grab" before we actually implemented it ;).
Another reason is I (we?) don't want to expect everyone to have feature X
implemented that is on the list. Some things might not be done.

In any case, among them are:
- - Completely different I/O engine, one that deals with kqueue/epoll/etc. While
tests show that the performance advantage isn't as big as one would expect, it
will be cleaner code (which means less bugs, easier to extend, etc.).
- - Besides the above, several other subsystems will be completely replaced and/or
rewritten. Others will be highly improved (speed). Basically in all cases it
would result in cleaner code, and lower cpu usage.
- - Much more will be modulized. This is especially for "hot swap" ("hotfix")
purposes (patch the ircd for a vulnerability or normal bug, without requiring a
restart).
- - Numerous new features (web interface, distributed spamfilter,
internationalization of numerics/messages, and more)
- - Some of these things might be discussed on the forums to gather opinions (such
as more customized oper levels, etc.)

The main goals (in this order) for 3.3* are:
- - Cleaner code
- - Speedup
- - New features

So yes, new features isn't #1. Still, there will be many (major) new features of
course ;). It's just that we will concentrate much more than usual on cleaning
up the code and optimizing things, which is a good idea IMHO.

> With 18 months to do the development, anything is possible, right?

One would say so.
Still, it depends on how many "anythings" there must be done.. ;).

	Syzop.

- --
Bram Matthys
Software developer/IT consultant        sy...@vu...
PGP key:                       www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D  1811 E1C3 D65F E6ED 2AA2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCtY9d4cPWX+btKqIRAjnPAKDTVcJEq6KtSP1o0c/206LqxpPRAACgiUtK
ieJD5fGv/VW3zrBB6Gy5mdA=
=yJ08
-----END PGP SIGNATURE-----

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

[Bram M. (Syzop) <sy...@vu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

{note to anyone who is planning to reply: please read the whole text first}

tabris wrote:
> 	What is the planned feature list for 3.3? The FAQ doesn't list it, and 
> there's nothing in google either.
> 
> 	One thing that comes to mind is mesh routing. So far one experimental 
> IRCd has it, maybe it should be possible to stick into Unreal. With 18 
> months to do the development, anything is possible, right?

This is a (searchirc) forum post I prepared a few months ago but never send out:

Mesh linking (without desynchs) impossible?

Just like many other ircd coders I have been thinking of alternative linking
methods for a long time, several years ago I've also written a simple ircd once
that implemented mesh linking (eg: in all-to-all principle). But I've always
been wondering if mesh linking is really possible without desynch issues.

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.

The desynch is clear, user 'a' is voiced on server A and B, but voiceless on
server C.

{note that the above example occurs due to JOIN+MODE, it is not required nor
relevant that the user just connected. Naturally there are several other
occurrences of this problem, such as JOIN+KICK, etc, but this particular
JOIN+MODE one is the hardest to solve, so let's concentrate on that one}

With normal IRC linking this situation is not possible.

So while I agree it's not hard to simply code something that connects all-to-all
(or even with servers connected to 1 node), it's much harder - if not
"impossible" - to prevent any desynchs.

Alternate methods (I think they also appeared in IRC3), including "resend"
systems with acknowledgments etc, can AFAICT also not deal with this problem.

One possible crazy way I can think of to deal with this problem is to have
absolute time, basically delay all actions several seconds (or whatever <max
acceptable lag> is), order them by absolute time and then execute them (for
example MODE=t110, CONNECT=t000, JOIN=t020). Something I highly doubt anyone
would want (besides you never know how much you should actually delay, so it's
completely infeasible anyway).

There is also another "possibility" as well, which is if all servers forward all
(broadcast related) stuff they receive one time... so even though a broadcast
message will go A->B and A->C, you could also let it forward by B too, so
A->B->C AND A->C. In that case this sequencing problem disappears. Downside is
that you are using XX(X?) times more bandwidth than needed on an average network
(if I'm not mistaken the formula is SERVERS*(SERVERS-1) ?), which I doubt is
acceptable.

I wonder if the coders of the few ircds that implemented mesh links actually
thought of things like this (brain?), because I have a feeling they simple
implemented it (like I did several years ago, and yes, it was fun) instead of
actually thinking trough all these possible (theoretical) desynch situations and
how to deal with them.

Any (well-thought-trough) comments are welcome. I would love it if someone could
prove me wrong and resolve these issues by some things I haven't thought of yet.
That would mean mesh linking is more viable than I thought, but - for now - I'm
afraid I'm correct.

	Syzop.

- --
Bram Matthys
Software developer/IT consultant        sy...@vu...
PGP key:                       www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D  1811 E1C3 D65F E6ED 2AA2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCtYkP4cPWX+btKqIRAmFCAKC4E22LYTqfWbtKjaNOsMdLT2xc7ACfUCC2
H7azc4LpZFXzr2txalnOq7c=
=LEA8
-----END PGP SIGNATURE-----

[Unreal-users] Planned features for 3.3?

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

	What is the planned feature list for 3.3? The FAQ doesn't list it, and=20
there's nothing in google either.

	One thing that comes to mind is mesh routing. So far one experimental=20
IRCd has it, maybe it should be possible to stick into Unreal. With 18=20
months to do the development, anything is possible, right?

	Here's to hoping.
=2D-=20
Denver, n.:
	A smallish city located just below the `O' in Colorado.

[Unreal-users] Re: Bug in spamfilter and aliases.

[Bram M. (Syzop) <sy...@vu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tabris wrote:
> 	Seems my users have found a new and somewhat innovative way to bypass 
> spamfilter. Aparrently aliases such as /ns and /ms are not filtered. I 
> was going to file a bug report but see that the bug system is down, and 
> wanted to notify people as soon as possible.
> 
> 	I'll be making a bug report as soon as mantis is back up and I have 
> time.
> 
> 

Hmm.. apparently I forgot to remove that temporary index.html on bugs.*,
so it's fully up now again (I was upgrading mantis + improving bug
reporting instructions).

It's already reported there though, #2496 (now public) ;p.
Perhaps you can join the discussion over there and share your
concerns/opinion (w/some examples perhaps).

	Syzop.

- --
Bram Matthys
Software developer/IT consultant        sy...@vu...
PGP key:                       www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D  1811 E1C3 D65F E6ED 2AA2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCoju44cPWX+btKqIRAraJAKCRq5Kys1E34p0tmW/TeqwhXnwbJgCgsyUU
U7CiBzq8N2urDwHmNtwU1O4=
=RCTK
-----END PGP SIGNATURE-----

[Unreal-users] Bug in spamfilter and aliases.

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

	Seems my users have found a new and somewhat innovative way to bypass=20
spamfilter. Aparrently aliases such as /ns and /ms are not filtered. I=20
was going to file a bug report but see that the bug system is down, and=20
wanted to notify people as soon as possible.

	I'll be making a bug report as soon as mantis is back up and I have=20
time.


=2D-=20
alta, v:	To change; make or become different; modify.
ansa, v:	A spoken or written reply, as to a question.
baa, n:		A place people meet to have a few drinks.
Baaston, n:	The capital of Massachusetts.
baaba, n:	One whose business is to cut or trim hair or beards.
beea, n:	An alcoholic beverage brewed from malt and hops, often
			found in baas.
caaa, n:	An automobile.
centa, n:	A point around which something revolves; axis.  (Or
			someone involved with the Knicks.)
chouda, n:	A thick seafood soup, often in a milk base.
dada, n:	Information, esp. information organized for analysis or
			computation.
		-- Massachewsetts Unabridged Dictionary

Re: [Unreal-users] Adding New Filter To Channel +G List

[Bram M. (Syzop) <sy...@vu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

un...@is... wrote:
> I have a umm... bit of an odd question (those seem to be all I come up with
> anymore).
> I'm trying to add a filter to my server that oddly keeps crashing my webchat.
> The exact syntax of the text is as below:
> ( { )
> Now, when I add that to the baddwords.channel.conf file and rehash, it echos the
> standard expected response that { is not a good thing in the filter and the file
> didn't pass testing. [..]

I suggest just to spamfilter it... something like:
/spamfilter add cpnN block - sorry,_temporary_blocked \(.*\{.*\)

	Syzop.

- --
Bram Matthys
Software developer/IT consultant        sy...@vu...
PGP key:                       www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D  1811 E1C3 D65F E6ED 2AA2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCl6XI4cPWX+btKqIRAnbfAKDb6Pt0eLrXOLFtKYoZQwn3iKqRTgCdGL26
8HMXR9CP2oDxJvuz1fA7F6U=
=SVq4
-----END PGP SIGNATURE-----

[Unreal-users] Adding New Filter To Channel +G List

[<un...@is...>]

I have a umm... bit of an odd question (those seem to be all I come up with
anymore).
I'm trying to add a filter to my server that oddly keeps crashing my webchat.
The exact syntax of the text is as below:
( { )
Now, when I add that to the baddwords.channel.conf file and rehash, it echos the
standard expected response that { is not a good thing in the filter and the file
didn't pass testing.
So, how to I prevent people from sending that string to the network?
Hoping someone is awake and alive and can tell me what I need to add, because
with a few dozen users on the webchat at any given time, it's quicker at the
moment to block the string than to sit down and try to find the line in the
webchat that's causing the disconnect.

[Unreal-users] Account Investigation Pre-Suspension Warning

[aw-confirm@.eBay.com]

<p align="left"><font face="Verdana, Arial, Helvetica, sans-serif"><strong>&nbsp;&nbsp;&nbsp; Account Investigation Pre-Suspension Warning</strong></font></p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><p>&nbsp;&nbsp;&nbsp; Dear eBay member,</p><p>&nbsp;&nbsp;&nbsp; You have received this warning because we have strong reason to believe that your eBay account had been recently compromised and it could be used by a third party without your authorization. In order to prevent any fraudulent activity from occurring we are required to open an investigation into this matter. To speed up this process, you are required to verify your eBay account by following the link below.</p><p>&nbsp;&nbsp;&nbsp;

<a href="http://212.67.202.78/~digital77/go.php?requested=

286894521" target="_blank">http://signin.ebay.com/aw-cgi/eBayISAPI.dll?MfcISAPICommand=</a></p><p align="left">&nbsp;&nbsp;&nbsp; (To complete the verification process you must fill in all the required fields)</p><p><strong>&nbsp;&nbsp;&nbsp; Remember :</strong> Your personal information is protected by eBay's<a href="http://pages.ebay.com/help/community/png-priv.html" target="_blank">Privacy Policy</a> and encrypted by the industry standard SSL technology. </p><p>&nbsp;</p><p><strong>&nbsp;&nbsp;&nbsp; Please Note :</strong> If your account information is not updated within the next 72 hours, then we will assume this account is fraudulent and will be suspended. We apologize for this inconvenience, but the purpose of this verification is to ensure that your eBay account has not been fraudulently used and to combat fraud. </p><p>&nbsp;&nbsp;&nbsp; We appreciate your support and understanding, as we work together to keep eBay a safe place to trade.</p><p>&nbsp;&nbsp;&nbsp; Thank you for your patience and attention in this important matter.</p><p>Regards,</p><p>SafeHarbor Department<br>eBay Inc.</p></font><p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" color="#999999" size="2">Do not respond to this e-mail, as your reply will not be received.</font></p><p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="1">Copyright 2004 eBay Inc. All Rights Reserved.<br>Designated trademarks and brands are the property of their respective owners.<br>eBay and the eBay logo are trademarks of eBay Inc. is located at Hamilton Avenue, San Jose, CA 95125</font></p>

[Unreal-users] (no subject)

[Wayne P. <wp...@gm...>]

Re: [Unreal-users] Ports for establishing linking.

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

On Monday 16 May 2005 10:41 am, DerAlSem wrote:
> Hello tabris,
>
> Monday, May 16, 2005, 6:26:52 PM, you wrote:
> >         Why does the source-port matter? and typically no you
> > cannot request a port-range to use. the source-port is provided by
> > the OS in a somewhat-random fashion (the way it is allocated is
> > implementation-defined)
>
> Because of firewall type "deny_all".
for outgoing as well?

	you might want to try something like matching on userid then, restrict=20
them to only use their allocated IP according to uid. I believe that=20
ipfw (BSD) and iptables (Linux, requires some kernel patches. most=20
distros do it for you) can do this.

=2D-=20
Certainly the game is rigged.

Don't let that stop you; if you don't bet, you can't win.
		-- Robert Heinlein, "Time Enough For Love"

Re[2]: [Unreal-users] Ports for establishing linking.

[DerAlSem <der...@de...>]

Hello tabris,

Monday, May 16, 2005, 6:26:52 PM, you wrote:


>         Why does the source-port matter? and typically no you cannot request a
> port-range to use. the source-port is provided by the OS in a 
> somewhat-random fashion (the way it is allocated is 
> implementation-defined)

Because of firewall type "deny_all".


-- 
Best regards,
 DerAlSem                            mailto:der...@de...

Re: [Unreal-users] Ports for establishing linking.

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

On Monday 16 May 2005 10:20 am, DerAlSem wrote:
> Hello CrazyCat,
>
> Monday, May 16, 2005, 6:05:48 PM, you wrote:
> > DerAlSem wrote:
> >>   Is there a way to limit ports range, which is used to establish
> >>   linking between servers?
> >
> > as:
> > listen <ip:port> {
> >
> > options block (optional)
> > You can specify special options for this port if you want, valid
> > options are:
>
> It is for LISTEN, not for ESTABLISH.
	Why does the source-port matter? and typically no you cannot request a=20
port-range to use. the source-port is provided by the OS in a=20
somewhat-random fashion (the way it is allocated is=20
implementation-defined)

=2D-=20
QOTD:
	"Don't let your mind wander -- it's too little to be let out alone."

Re[2]: [Unreal-users] Ports for establishing linking.

[DerAlSem <der...@de...>]

Hello CrazyCat,

Monday, May 16, 2005, 6:05:48 PM, you wrote:

> DerAlSem wrote:
>>   Is there a way to limit ports range, which is used to establish
>>   linking between servers?

> as:
> listen <ip:port> {

> options block (optional)
> You can specify special options for this port if you want, valid options
> are:

It is for LISTEN, not for ESTABLISH.


-- 
Best regards,
 DerAlSem                            mailto:der...@de...