mIRC Home    About    Download    Register    News    Help

Print Thread
#7638 21/01/03 09:19 AM
Joined: Dec 2002
Posts: 212
V
Fjord artisan
OP Offline
Fjord artisan
V
Joined: Dec 2002
Posts: 212
DISTRIBUTED SERVICES
or each servers plays the role of services
all the info is spreaded across servers
pros:
1) services are always online smile
2) there's no centralized power that controls them (in fact this is the main issue, since on most small networks supporting services, the one who has shell access is the big boss, and that leads to many problems. I've never heard of "abusing services power" problems on major networks, but I don't hang on them much)
3) services and ircd become more and more related (I mean on networks that support services of course;b) so uniting them ain't that senceless as it seems at first sight
4) even if the server is splited, everything goes on as usual - you can identify for your nickanme, use chanserv access, or send memos

There can be many problems tho. Like the sync. Each server has to keep it's own database and propagate all changes between servers. All the info should require timestamp, so the oldest timestamp tules over all others. Servers can propagate only changes to their database, every hub saves the timestamp of last split, so the splited server needs only the changes after that timestamp. Use of services may be disabled on splited servers.
In this concept there's no place for Operserv, since it's the major abuse source smile
Many of it features are realized already as server features, like jupe <-> resv {}, glines, others may be easily done, and many many more are not needed or can be used to abuse

Any opinions?


And all I need now is intellectual intercourse, a soul to dig the hole much deeper
#7639 21/01/03 12:14 PM
Joined: Dec 2002
Posts: 395
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Dec 2002
Posts: 395
Well, i think something like that already exists, in IRCX and ConferenceRoom.
I never used any of them though.
If this would really be better to have services in IRCds, it would be already implemented by major networks, don't you think? wink
This was discussed many times on various boards (dalnet@dal.net for example).

#7640 21/01/03 01:38 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
It is far better to have distributed services. The Big 4 don't bother with it because they arn't very advanced with anything at all. Don't forget 2 of the big networks don't even bother with Services at all which is just plain anacronistic, though I acknowledge that people go there because they like IRC in a more traditional sense and that is fine.

Look at the home of CR as a prime example. If there's ever a netsplit there's no longer a need to reidentify to your name when the split servers resynch, which alone reduces the load on Services by so much it's not worth the bother explaining further. Also less chance of channel takeovers, infact if the channel is run properly and passwords are hard to guess, chances are it's next to impossible. Responses from Services are also faster.

My network uses CR and I for one am looking forward to the upgrade to V2.X.

#7641 21/01/03 10:26 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Well based on your comment there I assume you have no technical background whatsoever? Because anyone who did would definately disagree with you. As someone who authors an IRCd and has worked with IRC Services I can tell you that integrating the two isn't a matter of "it will be hard" it is a matter of "it will be stupid". For example, my IRC network (~1500 users) has 5000 registered nicknames and 1300 registered channels. Doing a little math, well when a server links approximately 1GB of information would have to be sent to inform it of all the information contained in the databases.
And that is on a 1500 user network. Using a little more math, if there are 15000 users (100x 1500) that would mean you are now sending 100GB of information within the first 2 minutes of a server being connected. Remember services keep track of registered nicks, channels, memos, on some networks bots, etc. I can tell you this much, if a server on my network used 1GB of bandwidth within a 2 minute period the company hosting it would immediately kill the account. That means no more server. Not to mention all this increased bandwidth means increased processing which means increased lag. Also every server has to keep track of the information, so more memory usage. So lets see what we have? A CPU intensive, bandwidth hogging, memory eating, laggy server... Is that your vision of an ideal server? If it is then your comment about it being "far better" is correct, if on the other hand you want a fast server, then it is a horrible horrible idea.

Now to comment on your actual message:

Quote:
Look at the home of CR as a prime example. If there's ever a netsplit there's no longer a need to reidentify to your name when the split servers resynch


Wow you mean CR has a feature that every IRCd based on Dreamforge has? AMAZING! Dreamforge, Bahamut, Unreal, Ultimate, guess what? They all have this very same feature! It's called Services IDs. Not something CR invented, it's something that DALnet invented and CR just imitated.


To sum up... get your facts straight before you start making an argument.

#7642 22/01/03 03:42 AM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
So lets see what we have? A CPU intensive, bandwidth hogging, memory eating, laggy server... Is that your vision of an ideal server?

Then kindly explain why I, 12,000km away, can use Webnet with no appreciable lag? Knowledge of coding an IRCd has nothing to do with anything, I'm still able to read a lag meter. The network performs well and has good uptimes.

Speak in your technical one-upmanship tone of voice if you will but the statistics speak for themselves. As for your statement about distributed Services, I never claimed that Webmaster invented that or anything. I'm not an ambassador for them. I just oper on a server/network powered by the software they produce (not Webnet) so you can understand that I have faith in the product (not blind faith either). Now from my own observations, regardless of how qualified or unqualified you believe that to be (like who cares anyway) Webnet host what does seem to be the world's biggest IRC channel, getting 1800 or so on a good night, they have several other big channels and host around 25,000 - 30,000 concurrent connections.

If data transfer is, as you say 1GB or more after a resynch of split servers, and I'm not doubting your assumption, then it obviously doesn't bother anyone. It certainly doesn't do the network any harm.

You've obviously had a bad day, as you seem to have misinterpreted some of what I said. Perhaps it just annoys you that there's a commercial product out there that stacks up well against open source when the theory is put aside in favour of practice. That's life mate. grin

As for my technical background I have 13 years experience as an electrical engineer and spend alot of my time diagnosing faults in PC based building automation systems, both the hardware, software and the equipment the systems control as well as hospital building management, computer/phone data networks, medical imaging networks, electrical systems upto 11,000V, HVAC, steam boilers, steam powered sterilisation equipment, lifts, UPS, paging, fire, medical gases, and much more. No, on the other hand I have not coded an IRCd but don't take me for a mug or a 1st year Uni freshman either. I'm not silly and will always base my opinion of things on how well they work in practice, rather than on a drawing board filled with meaningless numbers. I guess that is why I am able to work in the one place for a long time and get paid accordingly. If you feel qualified to question this by all means I give you leave.

#7643 22/01/03 09:12 AM
Joined: Dec 2002
Posts: 212
V
Fjord artisan
OP Offline
Fjord artisan
V
Joined: Dec 2002
Posts: 212
NO NO NO!
You don't need to send ALL the information after split
JUST the differences
each hub server saves the splittime timestamp, so only records after that timestamp need to be synced
there are several other facts that can improve this sync - compression, reducing/removing some features, "using offline sync" if the server was lost for several days/months or it's a new server
And after all, a simple /list returns all that info, and it's only server to client.

On the other hand, it's not a matter of stupid, since nowadays ircds are involved in many services related issues: SVSNICK, SVSHINT, SVSJOIN, +rRM chanmodes, Identified info in whois, other services ids, some network's services SPOOF ability and much much more. So in fact services and ircd's exchange pretty much info, and in the concept of distributed services this is redudant.



And all I need now is intellectual intercourse, a soul to dig the hole much deeper
#7644 22/01/03 08:26 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Well I would comment on that (you have MANY problems in your idea) but apparently no one here cares about my opinion anyway, so I won't waste my time.

#7645 22/01/03 09:02 PM
Joined: Dec 2002
Posts: 395
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Dec 2002
Posts: 395
I care :tongue:

#7646 23/01/03 01:59 PM
Joined: Dec 2002
Posts: 212
V
Fjord artisan
OP Offline
Fjord artisan
V
Joined: Dec 2002
Posts: 212
Well problems are exactly what i want to hear! smile
And you've stated only the bandwith one
For me that problem is not that big, but well it's just our two different opinions
But I'm really looking forward to see all those problems
If you don't want to discuss it here privmsg me?


And all I need now is intellectual intercourse, a soul to dig the hole much deeper
#7647 24/01/03 10:14 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
NO NO NO!
You don't need to send ALL the information after split
JUST the differences
each hub server saves the splittime timestamp, so only records after that timestamp need to be synced


This means you need a caching system. You need to keep track of which records have been sent to which server. This means increased memory usage and processor time. A linked list would need to be kept as a member of each record. This linked list would then have to contain a string to all server's it as been sent to (need a string, not a pointer because if the server is split presumably no server record exists). This means that each database entry (memo, nickname, channel) has to have the additional memory usage of (8+name_len)*N

where name_len is the length of the name of the server, and N is the number of servers. So lets take an average servername, say name.mynet.com. Length is 15 (14 letters + the NULL byte). Average network has about 10 servers. This means that approximately 230bytes of memory would have to be allocated for each record. Now like I said on my network we have 5000 registered users, and 1400 channels. So doing the math, 230*5000 + 230*1400 = 1472000 bytes of memory. Thats 1.4MB of memory being used. Now keep in mind though, this is on my 1500 user network. Assuming those numbers are proportional to the size, if I had say 15000 users, that would mean I'd have 50000 registered nicks and 14000 channels. So doing the math again, 230*50000 + 230*14000 = 14.04MB. Now lets go on the scale of the "top 3" since the original posts were talking about that. If we have 150000 users, we'd have 500000 nicks and 140000 channels. So 230*500000 + 230*140000 = 140.38MB. And that isn't even taking into account the fact that there are other things services keeps track of such as memos, (possibly bots), akills, etc. So on a network the size of Quakenet, each server would be using approximately 200MB of ram just to store the services information, then you have to remember it also has to store regular user info. Yes running services on a single server will use about 200MB as well, but that can be taken into account. In that setup you need 1 machine with a lot of ram, in a distributed situation, all systems need it.

#7648 26/01/03 11:59 AM
Joined: Dec 2002
Posts: 212
V
Fjord artisan
OP Offline
Fjord artisan
V
Joined: Dec 2002
Posts: 212
Quote:
This means you need a caching system. You need to keep track of which records have been sent to which server.

Why?
1st case - the splited server is hub - after the split timestamp is exchanged and all the records after that timestamp propagate thru hubs, then to other ("regular") servers
2nd case - the splited server is "regular" - after the split it's hub sends all the info, and all this can be done in a way which prevents using services on splited servers, just like there's options to forbid new chans while splitted
If I've got you right,all this tracking is useless,well not exactly useless - of course in that way it will prevent any possible differences, but the price is too high as you've said. On the other hand, I don't beleive (and I don't know for sure) something like this is used with basic events like privmsg, and even without that tracking they work just fine
And one last thing - I don't beleive this is an issue for largest networks. One of the main reasons for this idea was to prevent abuse - not that I'm saying there's no abuse on top10, but on small networks way to many ppl try to play god, abusing every single feature they have power over. So by your calculations, less 10mb for 5000/2000 network will prevent abuse - this is too small price!


And all I need now is intellectual intercourse, a soul to dig the hole much deeper
#7649 26/01/03 08:54 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
He still hasn't answered my question yet. Given that he feels qualified to question my knowledge I would have thought he'd rise to the challenge, obviously not.

All I can do is reiterate what I said before. The network(s) employing distributed services seem to be doing well which means that codemastr's conspiracy theory of huge bandwidth and lag problems don't exist. Using CR as an example, where services are not only distributed but are embedded into the IRCd and not run as a seperate application anymore, the result has meant improved performance, not reduced.

#7650 26/01/03 10:03 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
I didn't answer your question because it wasn't worth answering.

Quote:
Then kindly explain why I, 12,000km away, can use Webnet with no appreciable lag?


12,000km is meaningless. Physical distance means nothing on the internet. The distance between servers (hops) is what matters. For example, I live in Pennsylvania, USA. I'm about 4 hops from England, where as I'm about 8 hops from Texas, USA. So geographical distance is irrelevant.

As for the last part, how should I know? I have no idea how Webnet works, if you can get someone from Webnet here to describe their system than fine. I told you the system I can up with would be lagged, perhaps they are using something I didn't think of. But you have provided no technical specs about their system, so how am I supposed to comment?

#7651 27/01/03 04:18 AM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
Physical distance means nothing on the internet.

That's true to an extent but you are forgetting that nothing in this world is 100% efficient. Electrical resistance will always be a factor in a latency test. Even fibre-optics isn't 100% efficient or infact anywhere near it. It just happens to be alot better than a copper pair.

#7652 27/01/03 06:56 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
If you are honestly going to tell me that the 1-2 nanosecond delay of a fiber optic wire is gonna cause a problem, well then you just proved my point of why I said that your question wasn't worth answering.

#7653 27/01/03 08:59 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
I didn't say it did. The question is worth answering or at least thinking about because it's a heck of alot more relevant to the performance of distributed services (the subject of this thread) than your last post. I've installed 100's of kilometres of fibre cable over the last 5 years, both as an employee of a company and as a contractor. I don't need to be told what it's performance is like.

Once again, this is proof that what works on paper doesn't always work in practice. At the end of the day maths just doesn't enter the equation (excuse the pun).


Link Copied to Clipboard