Photos Blog Random Things Links Guest Book Resume

AndyC.org : #Lecture

Performance Networking 1

Jan 2, 2003
Times are in PST

[16:14] * Joins: Washu[AWAY] (direwolf@adsl-64-170-153-115.dsl.sntc01.pacbell.net)
[16:14] <Commander-> :D
[16:14] <Commander-> PWN
[16:14] <Commander-> hey washu
[16:14] <Washu[AWAY]> bah
[16:14] <Washu[AWAY]> friggen inet
[16:14] <clsk> hehe
[16:14] * Washu[AWAY] is now known as Washu
[16:14] <Washu> alright...i be here
[16:14] <Commander-> you're late.
[16:14] * Commander- taps foot
[16:14] * Joins: nuvem (~StormWind@HSE-Toronto-ppp3489790.sympatico.ca)
[16:14] <Washu> I noticed...
[16:15] <Washu> Alright, well I'm ready
[16:15] * Joins: ibutsu[not-here] (Rell@CPE00b0d016d933.cpe.net.cable.rogers.com)
[16:15] <ibutsu[not-here]> need to add this too my list
[16:16] * Quits: Kicknfast (na@66-218-192-170.dialup.fidalgo.net) (Read error to Kicknfast[66-218-192-170.dialup.fidalgo.net]: Connection reset by peer)
[16:16] * Joins: calvin (calvin@brutaldeluxe.com)
[16:16] <ibutsu[not-here]> hey Washu
[16:16] <Washu> Ok, welcome to Performance networking. This will be a lecture on ways we can improve the performance of multiplayer.
[16:16] * Joins: SGT-T (SGT-T@66-218-192-170.dialup.fidalgo.net)
[16:16] * RedBeard sets mode: +v Washu
[16:16] * RedBeard sets mode: +m
[16:16] * RedBeard sets mode: +o Washu
[16:16] <Washu> I first want to start off with giving a basic overview of networking
[16:16] * Joins: synapse (synapse@alb-24-195-25-41.nycap.rr.com)
[16:17] <Washu> There are really 2 types of protocols used in networking, routed ones, and routing ones, I will focus mainly on the later
[16:18] <RedBeard> just to lay down the rules... msg an op if you have a question, and we might be taking off +m at random times to have discussion
[16:18] * Joins: Foper (x@CPE0020ed3613af.cpe.net.cable.rogers.com)
[16:18] <Washu> When you wish to send data across a network, it go's through several stages
[16:19] <Washu> the first is the actuall data, at which point it is broken into segments, of a size specified by the Transport layer protocol
[16:19] <Washu> such a protocol would be TCP
[16:19] <Washu> or UDP
[16:19] <Washu> each one of these protocols has a maximum size its packets can be...
[16:19] <Washu> then it is broken up into packets, which have the IP header appended onto them (if you are using IP)
[16:20] <Washu> and finaly it is broken down into frames...which is based on the medium you are transmitting the data through
[16:20] <Washu> for the standard home lan, this is Ethernet
[16:20] <Washu> and its MTU, or maximum transmition unit, is 1500 bytes
[16:21] <Washu> however, Dialup is significantly slower
[16:21] <Washu> but its MTU is also the same size (it uses PPP which has a MTU of 1500 also)
[16:21] <Washu> Now, the data that is generaly in these packets for a game would be updates
[16:21] <Washu> things like player posistions
[16:22] <Washu> the choice of what protocol to use to transmit them with TCP or UDP is a rather large one
[16:22] <Washu> if you look here: www.scapecaster.com/~sgtemp/packets.jpg you can see the differences in the sizes of the headers for each
[16:23] <Washu> 24 bytes vs 8 bytes
[16:23] <Washu> also
[16:23] <Washu> TCP uses a system known as windowing
[16:23] <Washu> this is a form of flow control where the two hosts negotiate a window size
[16:23] <Washu> which is the number of packets that can be sent
[16:23] <Washu> before a host ack's them
[16:23] * Joins: Divide (divide@e211115.upc-e.chello.nl)
[16:24] <Washu> if those packets are not received, it will timeout, and will resend the ENTIRE window
[16:24] <Washu> so, it has a tendancy of limiting your throughput
[16:24] <Washu> UDP on the other hand provides no such control, instead it just shoves them through as fast as it can
[16:24] <Washu> because of this, UDP is what games will generaly use
[16:25] <Washu> UDP is not reliable like TCP, if a packet is dropped, its lost, and if it arives before another to bad
[16:25] <Washu> Taking the example of firing a gun
[16:26] <Washu> generaly you would transmit the vector and posistion of the player at the time the gun was fired
[16:26] <Washu> this would allow the server to calculate a bullet trajectory
[16:26] <Washu> and thus determine if you hit anything
[16:27] <Washu> if you take said vector, you will note that it has 3 floating point numbers, and you need 3 more for the posistion, or 24bytes sofar
[16:27] <Washu> now, since you really don't need 32 bits of precision for a position
[16:28] <Washu> you could compress each position upon transmition to a 16bit float
[16:28] <Washu> this would save you 6 byes...which is quite a lot, when you consider that you want the client pumping packets as much as possible
[16:28] * Parts: mittens[Warcraft3] (narf@userd204.torchlake.com)
[16:28] * Joins: mittens (narf@userd204.torchlake.com)
[16:28] <Washu> because the more they get, and send, the smoother and more accurate the gameplay is
[16:29] <Washu> another thing to take into account is the minumum transmition unit...or the smallest size packet that will be sent
[16:29] <Washu> on ethernet this is 48 bytes
[16:30] <Washu> if you add in the ip header, and the udp header, it pretty much takes up most of that minumum size, with about 16 bytes left over
[16:30] * Joins: Tliff (Tliff@pD9049C49.dip.t-dialin.net)
[16:30] * Joins: KingDarka (KingDarka@pcp01327241pcs.pwayne01.pa.comcast.net)
[16:30] <Washu> so sending less than that would result in it being buffered by the driver
[16:30] * Parts: Tliff (Tliff@pD9049C49.dip.t-dialin.net)
[16:31] <Washu> Chat poses a problem for us
[16:31] * Joins: Exellon (tonyburns8@68.112.207.33)
[16:31] <Washu> since you don't want to loose important messages (as can happen with UDP)
[16:32] <Washu> now, Everquest (everyones favorite MMORPG...Right?) uses a second TCP socket
[16:32] <Washu> and transmits Chat data over that, along with important server messages
[16:32] <Washu> it then uses a UDP connection for regular game data
[16:33] * Quits: SGT-T (SGT-T@66-218-192-170.dialup.fidalgo.net) (Read error to SGT-T[66-218-192-170.dialup.fidalgo.net]: Connection reset by peer)
[16:33] <Washu> the TCP data is slightly compressed, reducing the overall size of it (TCP includes a compression scheme)
[16:34] <Washu> ok summary sofar: There is a minimum and maximum size of frames (and packets) and exceding these bounds results in either it being expanded, or broken up, respectively
[16:34] <Washu> TCP is generaly a bad solution for game data, too much overhead, while UDP provides little reliability, and no flow control
[16:35] <Washu> Compression of unimportant data, while CPU intensive (kindof) will result in less network traffic, thus improving gameplay
[16:36] <Washu> the average game packet isn't really that large, depending on the game, FPS's have a tendancy of taking the Lots of little ones approach
[16:36] <Washu> Another important thing, is testing
[16:36] <RedBeard> Question: doesn't half-life (and possibly other games) impose a go-between by using UDP and then having a custom layer to do the basic things that TCP does, like in-order arrival and no reproduction of packets?
[16:37] <Washu> They provide a basic scheme yes, but no where near as robust
[16:37] <RedBeard> and if so, would it be worth the bother of implementing that stuff, as opposed to using the 2-channel method (UDP and TCP)
[16:37] <Washu> that depends on your client base
[16:37] * X2 sets mode: +o Smoogle
[16:37] <Washu> If you are on Dialup, you will find that to be an optimal solution
[16:38] <Washu> but...
[16:38] <Washu> Broadband users often have problems with having multiple active ports open at one time
[16:39] <Washu> but yes, that is one way of solving it, and a fairly good way, as the majority of people won't have problems with it (including bb users)
[16:39] <Washu> but it increases the complexity of the server
[16:39] <Washu> as you now have to manage two connections per client
[16:39] <Smoogle> Their solution also makes it more difficult for poor-connection dialup users
[16:40] <Washu> Testing is important for two reasons
[16:40] <Washu> finding lag causing problems
[16:40] <Washu> and optimizing your networking routines
[16:40] <Washu> however, you can't do this if you test on a lan
[16:40] <Washu> as a lan if fast enough, that the lag generated by the game is very minor
[16:40] * Quits: blip (~asdf@co-ratlsnk-u1-c5c-221.clspco.adelphia.net) (Ping timeout for blip[co-ratlsnk-u1-c5c-221.clspco.adelphia.net])
[16:40] <Washu> so you may get results that apear optimum, but are far from it
[16:41] <RedBeard> is there some network testing suite that can impede the flow of packets artificially?
[16:41] <Washu> depends
[16:41] <Washu> DirectPlay does have such a facility
[16:41] <Smoogle> that requires you use directplay however :/
[16:41] <Washu> but if you are using Sockets, unless you wish to spend thousands on a hardware flow control device, no there isn't
[16:42] <Washu> of course, I can offer you all deals on such devices ;)
[16:42] <Washu> now, you could implement one of your own
[16:42] <RedBeard> i see. nothing that could be done by subverting the network communication drivers?
[16:42] <Washu> those also cost lots of money
[16:42] <Washu> and most network admins disaprove of them, plus they have to be card specific
[16:43] <Washu> but you could make your game connect to a packet router on your machine
[16:43] <RedBeard> i see. so you really do need to just get a free AOL for a month to test stuff out eh?
[16:43] <Washu> and have it perform the flow control
[16:43] <Washu> or that, that's actually a better solution, because then you have a true dialup connection, and it will sometimes really suck
[16:44] <Washu> but, it will get you accurate results
[16:44] <RedBeard> yes, true real-world testing
[16:44] <Washu> after identifying that you have problems with your network routines
[16:44] <Washu> you need to isolate them
[16:44] * Joins: Kicknfast (na@66-218-193-187.dialup.fidalgo.net)
[16:44] <Washu> two things help here
[16:44] <Washu> packet id's
[16:44] <Washu> and a packet sniffer
[16:45] <Washu> if you can identify (by looking at the data) whats being sent, where, when, and how much, plus any extra overhead
[16:45] <Washu> then you can figure out ways of reducing the total number of said packets that need to be sent
[16:46] <Washu> as the fewer you send, the less that modem will choke
[16:46] <Washu> so far comments
[16:46] * Washu sets mode: -m
[16:46] <Smoogle> ?
[16:46] <Washu> le comment
[16:47] <mittens> le commento
[16:47] <Smoogle> good so far, though you could hit enter a little less often :P
[16:47] * Exellon is now known as grins
[16:47] <Washu> sorry, bad habit I got into because of trent
[16:47] <mittens> washu thinks in fragments
[16:47] * grins is now known as Exellon
[16:47] <mittens> :)
[16:47] <Washu> ok..off I go again...
[16:47] <RedBeard> you got the channel all to yourself man, so try to cleanse your bad habit :P
[16:47] <Smoogle> also, isn't it possible to restrict outgoing/incoming bandwidth using the connection manager stuff on XP ?
[16:48] * RedBeard sets mode: +m
[16:48] <Washu> Maybe, I haven't really played with it
[16:48] <Washu> if so, that would help in testing (no free AOL cd's available?)
[16:49] <Washu> but nothing beats the real environment, plus you cannot simulate things like a network failure in pacbell that has your packets getting routed through australia, and thus introducing lag time, not so much speed problems
[16:49] <Smoogle> well, in my situation it would be no modem available
[16:49] <Washu> unless you have a cisco lab handy
[16:49] * Washu coughs
[16:49] * Smoogle punches Washu - back to our world
[16:50] <Washu> also, another problem with the FPS idea of many small packets is that a modem is limited in how fast it can send the data, not so much how mcuh
[16:50] <Washu> so you end up creating a rather large backlog of packets that need to be transmitted...which then get overwritten by a new packet with a far of posistion, intoducing jumping
[16:51] <Washu> or teleporting, or whatever you like to call it
[16:51] <RedBeard> "warping" also
[16:51] <Washu> bah, all the different names for the same thing
[16:51] <Smoogle> not entirely
[16:52] <RedBeard> <Exellon> I realize this may be slightly off topic, but what part does security (namely authentication and encryption) play in networking related to games?
[16:52] <Washu> lag prediction algorithms help here...
[16:52] <Washu> hrm...that depends
[16:52] <Smoogle> dead reckoning?
[16:52] <Washu> taking the example of Half-Life
[16:52] <Washu> passworded server use a simple method of transmitting the password
[16:52] <Washu> for authentication
[16:53] <Washu> however, for something like Everquest, UO, Shadowbane and such
[16:53] <Washu> it uses a full array of Public/Private keys
[16:53] <RedBeard> i'm not sure if exellon meant for means of hacking (aimbots, packet sniffing, etc)
[16:53] * Smoogle sets mode: +v Exellon
[16:53] <Washu> as for that: As much as can be done on the server, should be
[16:53] <Smoogle> what did you mean.
[16:54] <Washu> If you fire a gun, have the server determine where the bullet went, have the server do collision detection, and the client also
[16:54] <Exellon> i mean like, for sending maps and such
[16:54] <Washu> updating the client?
[16:54] <Exellon> how might you prevent people from intercepting them and tampering them
[16:54] <Exellon> when theyre being sent to the other players
[16:54] <Washu> use a hash, or a crc
[16:54] <Washu> well
[16:55] <Washu> if you are in a client server environment
[16:55] <Washu> that's not very probable
[16:55] <Washu> unless they are on the server
[16:55] <Smoogle> or commandeered a very convient router ...
[16:55] <Exellon> i c
[16:55] <RedBeard> washu - i believe the way aimbots work is they keep track of the player positions by recording them from incoming update packets, and then when the player sends a "fire" packet, it inserts a "rotate x,y" packet first to correct your aim
[16:55] <Exellon> question answered
[16:55] <Exellon> .down
[16:55] * X2 sets mode: -v Exellon
[16:56] <RedBeard> how could you try to thwart that effort?
[16:56] <Smoogle> sequencing numbers
[16:56] <Washu> RedBeard: yes, howver, as long as you have the server doing things like projecting the bullet trajectory, that will help some (ie a slightly randomized vector for the bullet)
[16:56] <Washu> also, a sequencing system will help...but that is fairly easy to crack
[16:57] <Washu> when they log into the server have is validate their files
[16:57] <Washu> as a aimbot generaly uses collored models
[16:57] <Washu> ie: all green terrorist...
[16:57] <Smoogle> not usually
[16:57] <Smoogle> those are a different kind of mods
[16:57] <RedBeard> the one i was talking about uses nothing but packet sniffing and math
[16:57] <Washu> every halflife, and q2 ones I have found
[16:57] <Smoogle> aimbots are what redbeard described, a program running externally that modifies incoming/outgoing packets
[16:57] <Washu> have used colored models to find and aimyou
[16:58] <Washu> in that case, there isn't much you can do
[16:58] <Washu> Except, like I said: have the server do as much as possible
[16:58] <RedBeard> i see. so where were we?
[16:59] <Washu> player wants to turn, have it ask the server, player wants to shoot, have it ask the server, player wants to move...you get the idea
[16:59] <RedBeard> lots of small packets cause a backlog...
[16:59] <Washu> yes
[16:59] <Washu> lots of small packets become lots of large packets
[16:59] <Washu> because: when you send your small packet, it gets a lot of headers appended to it
[17:00] <Washu> and can grow in size very quickly, the other problem is: if you are using TCP then Many os's, including windows, will delay sending packets to group them together into a large one, creating lag
[17:00] <Washu> you can disable this ofcourse, but none the less, it is there
[17:01] <Washu> Broadband users have a unique problem
[17:01] <Smoogle> it isn't possible to disable that in a non-platform-specific way, is it?
[17:01] <Washu> no, its not
[17:01] <Smoogle> k, continue
[17:01] <Washu> since its not part of the standard, its implemented differently on each TCP/IP stack
[17:02] <Washu> A: They generaly have a high down bandwidth
[17:02] <Washu> B: also have a slow up bandwidth
[17:02] <Washu> C: PPPOE Has flow control in it
[17:02] <Washu> so, even if you are using UDP, there is still a rudimentry form of flowcontrol acting on your data
[17:03] <Washu> this causes lag...thus inducing the symptom of: I can see you moving, but I cannot move
[17:04] <Washu> This also causes another problem in that the slow upload will get even worse if TCP is running, since it will limit the Down stream because of the time it takes the ACK's to get back via the upstream
[17:04] <Washu> Also: many home routers have firewalls built into them
[17:04] <Smoogle> so?
[17:05] <Washu> These firewalls work on the principal of blocking ports, and can prevent incomming connections
[17:05] <Washu> They also will limit the maximum number of outgoing ports
[17:05] <Washu> this is our major concern
[17:05] <Washu> because if they cannot open an outgoing port to our server...they can't play
[17:06] <Washu> This generaly requires the client to reconfigure the router....not a friendly aspect...and not much you can do about it
[17:06] <Smoogle> What do they generally limit it to?
[17:06] <Washu> 32 outgoing connections
[17:06] <Washu> is what Netgear has it set to on mine
[17:06] <Smoogle> Is it changeable?
[17:06] <Washu> others have fewer, like ibutsu's
[17:07] <Washu> mine is
[17:07] <Washu> some aren't
[17:07] <Washu> some are just dummy routers (ie plug and play)
[17:07] <Washu> they offer security, but at a rather steep cost
[17:08] <Washu> and if they have anything running in the background
[17:08] <Washu> like windows update, aim, msn, and pretty much all software nowdays
[17:08] <Washu> its got something going out
[17:09] <RedBeard> any idea what linksys allows? that's the brand my house uses
[17:09] <Washu> what model? it differes based on model also
[17:09] * Joins: POP3Y (ayici@213.58.81.253)
[17:09] <RedBeard> uhm, it's a couple years old
[17:09] <Washu> and not really...Linksys isn't used much in the industry
[17:09] * Smoogle is slightly worried now
[17:09] <Washu> (well, my industry
[17:09] <Smoogle> i was going to buy a router, and this is a new problem :/
[17:10] * Quits: POP3Y (ayici@213.58.81.253) (G-lined (<Dukemaster> [spam] Please do not spam AfterNET.Org))
[17:10] <RedBeard> so that's why cisco routers are so expensive eh
[17:10] <Washu> its primary market is home lans...and so a limit of 32 sounds rather large
[17:10] <Washu> expensive? :P that one way of putting it
[17:10] <Washu> also, some of the older routers didn't have a limit
[17:11] <Washu> their security aspects were not high as the time (as the prevalence of bb at the time was not great enough to promote hacking)
[17:11] <Washu> about network security:
[17:12] <Washu> Any port that is listening for packets MUST (read should) use some form of limiting the maximum buffer size it will accept
[17:13] <Washu> otherwise you are prone to buffer overflows which can, and will allow hackers to gain access to your system, and while I know everyone thinks...oh, why would they do that to my little homelan... well, its there, its open, its a prime target to hone 1337 sk1llz one
[17:13] <Washu> *on
[17:14] <Washu> another thing is: the server should do as much as possible, ie: the player makes a request to do something, and the server either allows it, or doesn't
[17:15] <Washu> umm, ok comments time while I think
[17:15] <Washu> and questions, statements, garbage
[17:15] * Washu sets mode: -m
[17:15] <Washu> Speak thine minds, I do not bite...much
[17:16] <Washu> ok then, lag prediction, then I'm done for tonight....meh food is getting close to being done
[17:16] <Washu> The problem with lag prediction, and multiplayer games in general, is that you are dealing with old data
[17:17] * RedBeard sets mode: +m
[17:17] <Washu> common ways of dealing with this include dead reconing
[17:17] <RedBeard> just thought i'd comment that physics simulations also have problems with slow framerates, which is a similar thing to having network lag
[17:18] <Washu> You can do simple things, like keep moving the player along their current vector, at their current speed till a new update comes along
[17:18] <RedBeard> so it's a rather universal problem
[17:18] <Washu> good point
[17:18] <Washu> and it can make you think that its laggy server wise, when its not
[17:18] <Washu> that's where the packet sniffer comes in
[17:18] <Washu> also, be warned a packet sniffer introduces lag
[17:19] <Washu> noticeable lag
[17:19] <Washu> another way that I have read about is to use splines that take the last few updates and uses them to create a prediction
[17:20] <Washu> of where the player currently is, not very feasable for a FPS
[17:20] <Washu> but for something like and RPG, it could be very hand
[17:20] <Washu> *+y
[17:20] <RedBeard> i believe i've seen that at work in games like neocron (FPS MMORPG mix)
[17:20] <Washu> if I recall correctly one of their programmers was the one who wrote said document that I read
[17:20] <Washu> it works...
[17:21] <Washu> and it works well
[17:21] <Washu> you don't get warping
[17:21] <Washu> or teleportation of any kind
[17:21] <Washu> as the new position mearly is used to smoothly move the player
[17:21] <Washu> hrm, if I find that article I'll link it
[17:22] <Washu> other ways include using the new position and the current client predicted position to average it out
[17:23] <Washu> this introduces minor teleportation, but itsn't that noticable, except at high speeds
[17:23] <Washu> and, if its not going to support internet play, you can forget lag prediction, and move the player along their current known vector, as the packets will be coming in fast enough for it to not matter
[17:24] <Washu> hence why some games have the optimize for lan play
[17:24] <Washu> checkbox
[17:24] <Washu> it will do a couple of things, increase the number and size of packets
[17:24] <Washu> and reduce the complexity of the lag prediction being done
[17:25] <Washu> the good thing about lag prediction, is that for some games (nwn and many others) it makes it so that you have to send fewer updates
[17:25] <Washu> which means more players per server, which of course intoduces communities, and players love those
[17:26] <Washu> umm, that's all that I can really think of right now, without getting down into to much techinical detail
[17:26] <Washu> ooh
[17:26] <Washu> one last thing...
[17:26] <Washu> OOB data
[17:26] <Washu> or out of band data
[17:26] <Washu> TCP supports it...in windows
[17:26] <Washu> as do berkeley sockets
[17:27] <Washu> The problem with using OOB for important messages (player join/leave)
[17:27] <Washu> is that it may not end up on the receiving side as OOB, as routers have the ability to change said flag if configured to...
[17:28] <Washu> this is usefull if its a lan only game, or if you implement your own OOB solution, but using the TCP version is not recommended
[17:28] <Washu> also, doom has ports 666 for use if you want to put your game on them
[17:28] <RedBeard> what does "out of band" mean, and what's it do?
[17:29] <RedBeard> and is it "band" or "bound" ?
[17:29] <Washu> It marks the message as being not of the same priority as the rest of the packets in the stream
[17:29] <Washu> band
[17:29] <Washu> its basicly like saying HEY, I'm more important
[17:29] <Washu> and its used between internet routers for important messages, but you can also use it for TCP based solutions
[17:30] <Washu> however, as the internet is comprised of many different systems, some networks, and routers end up removing this flag to compensate for technical crap
[17:31] <RedBeard> i have a question about compression stuff (trimming 32-bit floats to 16 and that kind) - can you implement stuff on the server that will alter the compression on a per-connection basis, so people with poor connections get a slightly less accurate version of the information but still get the information at a reasonable rate, while faster connections can get more accurate data?
[17:31] <Washu> yes
[17:31] <Washu> however, it will make the server more complex to manage
[17:31] <Washu> and increase the code base significantly, but otherwise, there is nothing to stop you from doing that
[17:32] <Washu> infact, you could implement a rudimentry form of flow control also
[17:32] <Washu> so that slower connections drop fewer packets
[17:32] <Washu> and faster ones get more
[17:32] * Quits: nuvem (~StormWind@HSE-Toronto-ppp3489790.sympatico.ca) (Read error to nuvem[HSE-Toronto-ppp3489790.sympatico.ca]: EOF from client)
[17:32] <Washu> but again, you have the Broadband issue of a slow upstream that can artificialy slow a line down
[17:32] <RedBeard> i see
[17:33] <Washu> take my line for instance...
[17:33] <Washu> I have 1.54Mb/s down
[17:33] <Washu> but only 128Kb/s up
[17:34] <Washu> when I download 2 files, from different servers...that are very fast... I don't get half the speed, but more like a quarter, because I have two streams of acks going
[17:34] * Washu is away for a second
[17:35] <Washu> back
[17:35] <Washu> Switched vs Hub based networks for cluster based servers
[17:35] * Joins: Phoenix (bob@dsc04-ati-ga-1-248.rasserver.net)
[17:35] <Washu> Switched networks have almost no collisions
[17:36] <Washu> because each host on a switched network has a dedicated line to it
[17:36] <Washu> while with a hub based network, all hosts share the bandwidth/line
[17:36] <Washu> thus for such an environment like a MMO, a switched network is best
[17:36] <Smoogle> MMO?
[17:37] <Washu> Massivly Multiplayer
[17:37] <Washu> Online
[17:37] <Smoogle> ah, just wondering as it wasn't a complete noun :P
[17:37] <Washu> covers all MMO games, RPG, FPS, SG..etc
[17:37] <RedBeard> "MMOG" perhaps?
[17:38] <Washu> That's better
[17:38] <Smoogle> bbl
[17:38] <Washu> Also, for such an environment you will generaly have gigabit, or faster going between your servers
[17:38] <Washu> eh...away for a sec, gotta go get some things
[17:40] <Washu> ok
[17:41] <Washu> And now, a little about me: I am Washu, The Greatest Scientific Genius in the Universe...I also currently work for Sun Microsystems as a network administrator, Have a CCDP, a CCNP, and am currently working on my CCIE
[17:41] <Washu> Oh yes, and I can program
[17:42] * Joins: nuvem (~StormWind@hse-toronto-ppp3489790.sympatico.ca)
[17:42] * Washu sets mode: -m
[17:42] * mittens bites washu
[17:42] <Washu> :P
[17:43] <Washu> Which will add another $100 to my consulting fee's btw
[17:43] <mittens> you free to talk now?
[17:43] <Washu> yes
[17:43] <Washu> OMG, I Am speachless, I can't TALK
[17:44] * Quits: Smoogle (smoogle@CPE-203-45-70-158.nsw.bigpond.net.au) (Read error to Smoogle[CPE-203-45-70-158.nsw.bigpond.net.au]: Connection reset by peer)
[17:44] * Joins: Smoogle (smoogle@CPE-203-45-70-158.nsw.bigpond.net.au)
[17:47] * Joins: jwvanderb (~jwvanderb@73.64.35.65.cfl.rr.com)
[17:49] * synapse is now known as synapse|away
[17:51] * Quits: nuvem (~StormWind@hse-toronto-ppp3489790.sympatico.ca) (Canadian dorks are 5-dimensional hyper-surfaces embedded in Klein-Grassman quadric manifolds)
[17:53] <Divide> nice lecture, Washu
[17:53] <Epidemi> Definatly :)
[17:53] * Quits: Exellon (tonyburns8@68.112.207.33) (Ping timeout for Exellon[68.112.207.33])
[17:54] <Phoenix> I wouldnt think a 'hub situation would really apply to MMOG
[17:54] <Phoenix> more of a LAN related setup isnt it?
[17:55] <Washu> well
[17:55] <Washu> ok...when you have a mmog, you have a server cluster
[17:55] <Washu> the entire mmog world is not on one server...as that would be very slow
[17:56] <Phoenix> basically continents
[17:56] <Washu> imagine eq running on one server? you would need a super computer to handle 1500 players
[17:56] <Washu> not to mention, the database would be enourmous (several hundred gigs
[17:57] <Washu> Distribute that over 4 servers though
[17:57] <Washu> and now you have something you can work with
[17:57] <Washu> plus you can expand the world dynamicaly by adding servers
[17:57] <Phoenix> same as EQ and ultima online
[17:57] <Phoenix> is ultima online still around?
[17:58] <Washu> yes
[17:58] <Washu> ahh, food, brb
[17:58] <RedBeard> jwvanderb, i velieve you did a bit of work on everquest?
[17:58] <jwvanderb> Yes
[17:59] <jwvanderb> I worked as an intern on the original netcode
[17:59] <RedBeard> any insight into what kind of systems it really uses?
[17:59] <jwvanderb> one sec while I read what was said...
[18:00] <jwvanderb> Yes, essentially that is what EQ uses...
[18:00] <jwvanderb> An EQ "Server" is a cluster of machines.. each machine runs from 2-4 seperate zones
[18:00] <jwvanderb> They probably run even more now though heh
[18:01] <Washu> with the more power available to servers now...i wouldn't be surprised
[18:01] <jwvanderb> But at the time, about 2-4 zones, depending on the load expected from the zone, both player-wise and AI-wise
[18:01] <jwvanderb> There is however a central DB that all the zone servers connect to.. 1 database per "player server"
[18:02] <Washu> ahh, wasn't sure about that...do you happen to know what kind of a db server it was?
[18:02] <jwvanderb> Oracle
[18:02] <Washu> it could be a cluster then...as oracle makes that fairly invisible
[18:02] <jwvanderb> The DB layout was actually one of the weaker sides of the implementation
[18:02] * mittens is now known as mittens[mooooooovie]
[18:03] <Washu> although...it happens
[18:03] <Washu> same goes for DaoC, and using MySQL
[18:03] <jwvanderb> DaoC uses MySql?
[18:04] <Washu> yeah, shocking isn't it
[18:04] <jwvanderb> Not really
[18:04] <jwvanderb> i've always advocated that MySql was caopabale of andlign such a system
[18:04] <jwvanderb> I'm glad to see proof of it :)
[18:04] <Washu> lol
[18:04] <Phoenix> Ill have to review the lecture later... which means Ill be harassing washu later :)
[18:04] <Washu> They have their problems
[18:04] <RedBeard> i'll have the log of the lecture on my website later, for all interested. link is in channel topic
[18:04] <jwvanderb> We all have our problems :)
[18:05] <Washu> I think the main problem DB's have is that they are build to handle Manipulating the data, not so much fetching it
[18:05] <jwvanderb> The implementation for EQ was realyl a disaster to maintain, woudl problems cropping up constantly
[18:05] <Washu> still cropping up
[18:05] <jwvanderb> the largest problem with use of a DB on such scale is that it is extremely prone to data corruption
[18:06] <Washu> well, that and the DB designer is usualy from an industry where you don't have these type of demands placed on the server
[18:06] <jwvanderb> I remember one time in EQ where the item database got corrupted where every item form 2000-3000 was fubared
[18:07] <RedBeard> yeah, database design is generally regarded as a mundane task that doesn't need incredible performance...
[18:07] <Phoenix> I disagree
[18:07] <Washu> well...its more like the way they are designed for the demands are different
[18:07] <RedBeard> _generally_
[18:07] <Washu> there was an article on gamasutra about it
[18:08] <Phoenix> databases are designed to complete queries with some speed, but I dont think the demands are 'exactly' the same as to the form of the data
[18:08] <Washu> www.gamasutra.com/resource_guide/20020916/hallenberg_01.htm
[18:09] <jwvanderb> unfortunately there isn't another viable alternative data storage for mmorpgs to use
[18:09] <jwvanderb> you just have an insane amoutn of data to handle
[18:09] <Washu> yes
[18:09] <Washu> and lots of ram
[18:09] <Washu> LOTS of RAM
[18:09] <jwvanderb> :)
[18:09] * Washu has lots of ram
[18:09] <RedBeard> i think the databases could be distributed or separated
[18:10] <Washu> makes maintaining it harder though
[18:10] * Phoenix codes it in foxpro!
[18:10] <RedBeard> i suppose
[18:10] <Washu> and you now have to pay a pro his 100k a year
[18:10] <jwvanderb> on the contrary.. if I Was redoing EQ's data storage system, the first thign I Would do is take all data that is consistant from server to server (items, zones, npcs, etc) and make all player servers use one single DB with that data
[18:11] <jwvanderb> with of course backups
[18:11] <Washu> then design a system just for the dynamic data to allow for fast modifications
[18:11] <jwvanderb> but for operational use, they'd all access the same DB
[18:11] <jwvanderb> exactly
[18:11] <jwvanderb> If you remove the consistant data, whats left is at a scope that can eb handled possibly with more efficient means
[18:12] <jwvanderb> Player Data, Guilds, Manufactured Items.. thats abotu all that is unique per server
[18:12] <jwvanderb> so pull that out, and handle it on a per server basis with a more optimized method
[18:13] <jwvanderb> afk
[18:16] <Washu> sweet mother of god
[18:17] <Washu> that's almost my entire line of thought put to words
[18:17] <Washu> including the AFK part
[18:18] <Washu> can I borrow your brain for a bit...need to download it
[18:20] * Quits: Divide (divide@e211115.upc-e.chello.nl) (BitchX: born to raise hell)
[18:21] * Epidemi is now known as Divide
[18:24] <jwvanderb> lol
[18:25] <Washu> anyways, I'm out of here...need to go do somethings, and this headache is killing me
[18:26] <Washu> so, it was enjoyable hearing myself talk for a few hours without interuptions...maybe some other time I'll actually give you nitty gritty


Text file last modified on April 28, 2007, 10:28:25 PM, MST.

All content Copyright © 2024 Andy Campbell.
Permission to reproduce content, in any format,
by explicit written permission of author only.
"Honesty is the best policy - when there is money in it."
- Mark Twain