Jump to content

  • Log In with Google      Sign In   
  • Create Account


Incoming hilarity: abaraba is back, and this time he's fixated on P2P networking!


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
82 replies to this topic

#61 hplus0603   Moderators   -  Reputation: 4955

Like
0Likes
Like

Posted 06 September 2009 - 09:34 AM

Quote:
My current reality is that P2P allows for a higher maximum number of player than Server-Client does in the case we don't use dedicated servers


Actually, the one crucial assumption is that everyone has the same upload limitations. If that is true, then P2P will allow larger amounts of clients than C/S -- but only up to some small amount of clients, like 16 or 32, because limited upload is, well, limited :-)

As soon as you can find one user who has better than average upload, then C/S gives you a lot of benefits, including an authoritative server, larger player counts (even for players with much more limited upload), etc. And that server is, generally, a normal playing doing "hosting," not a dedicated server paid for by the game publisher.

When it comes to RTS games, I'm not so sure they are all P2P -- if you look at Starcraft, for example, it has a clear host, and when on the Internet, it goes through battle.net to avoid NAT problems. I wouldn't be surprised if it actually was C/S topology with the "host" as the server. However, it doesn't matter much, because with 4-8 players, neither model is all that different in network bandwidth usage, so other implementation worries probably weigh more heavily.



Sponsor:

#62 NickS   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 06 September 2009 - 06:40 PM

[Most Text Deleted by Moderator]

* Donnybrook is a collaboration between Microsoft Research and the Carnegie Mellon University, the system was at the basis of simulation results involving battles of approximately 900 players interacting simultaneously.

* Players are satisfied by Donnybrook in a low bandwidth environment as they are by Quake III in a high-bandwidth environment, e.g. a LAN.

[Edited by - Promit on September 7, 2009 12:40:51 PM]

#63 Super-Sandra   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 06 September 2009 - 06:46 PM

Quote:

Phosphor is a first-person shooter created with Macromedia Director. The Shockwave Player allows the game to run within a web browser on Windows and Mac OS computers. Both single player (with AI-controlled bots) and multiplayer (using peer-to-peer Internet or LAN connections) game modes are supported. Our goal is to create a gaming experience similar to classic FPS games.

http://www2.rasterwerks.com/game/phosphor/beta1.asp


This guy not only implemented P2P multiplayer instead of server based approach, but he also coded a first-person shooter in Macromedia Director instead of C++, what a moron.

#64 Codeka   Members   -  Reputation: 1153

Like
0Likes
Like

Posted 06 September 2009 - 07:41 PM

Quote:
Original post by NickS
* Donnybrook is a collaboration between Microsoft Research and the Carnegie Mellon University, the system was at the basis of simulation results involving battles of approximately 900 players interacting simultaneously.
Where do you get the number 900 from? From the papers linked so far in this thread (and all the other papers I have found), it seems to me they're testing only 2 players at a time, with 30 bots (i.e. 32 players in a single game).
Quote:
Original post by NickS
* Players are satisfied by Donnybrook in a low bandwidth environment as they are by Quake III in a high-bandwidth environment, e.g. a LAN.
That's still comparing Donnybrook P2P in low-bandwidth to "naive" P2P in high bandwidth, though. It's not comparing Donnybrook P2P with C/S. Also, the "low bandwidth" Donnybrook is 108Kb/s upload which is already at the limit of many people's broadband plans - that is, even Doonybrook does not scale past 32 players on a standard broadband plan*.




*Technically, Donnybrook bandwidth requirements are supposed to scale better than linearly in the number of players, but it's still not "free".

#65 Gaffer   Members   -  Reputation: 422

Like
0Likes
Like

Posted 06 September 2009 - 08:12 PM

It's been a while since I read the donnybrook paper, but it seemed to me really it's just all about encoding a higher level representation of the actions being performed, then playing it back roughly in sync using much smarter locally running interpretive AI actions

eg. get from A to B, I don't really care how you do it - just do it, climb the wall, jump whatever

In other words, just another one of those classic trade-offs between consistency and throughput

The end result being you don't need such a high frequency of updates to get smooth realistic motion of players and AIs in the remote view - you can get away with something like one update per-second vs. the usual 10 or 20

(but then again, if I'm missing something let me know ... it's been a long while since I've read that paper)

cheers

#66 Codeka   Members   -  Reputation: 1153

Like
0Likes
Like

Posted 06 September 2009 - 08:27 PM

Another thing to consider is the complexity of implementing the Donnybrook solution, compared to the way it was done in "normal" C/S Quake 3. The way it was implemented in C/S Quake 3 is practically the most naive solution possible while still providing for 32 players (in fact, if you read what he says, it seems Carmack simplified the implementation a lot since the original QTEST).

Donnybrook is far more complex than the C/S implementated in Quake 3, and it doesn't seem to work any more efficiently than C/S quake.

#67 Antheus   Members   -  Reputation: 2393

Like
0Likes
Like

Posted 06 September 2009 - 11:32 PM

This thread is a complete mess.

NickS, if you are author or in any way related to the Donnybrook project, it would help to state so.

If you are abaraba, then stop copy pasting sections from the documents. We can read and comprehend, have already done so, and understand what the article says, it is just pointless to comment.

And I have no clue where that rasterwerks link came from or why it matters, except to show author's comment that P2P doesn't work in real world.

Either way, this one way regurgitation of unrelated quotes and terms has gone well beyond any measure of good taste or rational thought. Finnegan's Wake is light reading compared to this.

#68 hplus0603   Moderators   -  Reputation: 4955

Like
0Likes
Like

Posted 07 September 2009 - 05:50 AM

Quote:
There is a growing desire to use the machines of participants themselves rather than separate dedicated servers to provide resources for serving games.


Do you have any support at all for this statement?

In my experience, it used to be that users would host, because hosting was expensive. These days, hosting is cheap. Thus, /users/ will pay for dedicated servers (just jump on any C/S:S session -- almost all the servers are hosted at ServerBeach or Gameservers or whatever).

When it comes to large-scale P2P solutions, I still recommend you look into the VAST project. However, it's also been my experience that when people try to really deliver large systems on P2P, they end up adding more and more C/S-like systems, until suddenly the P2P turns out to be something like a C/S set-up with P2P-elected dynamic servers...

Finally, Xbox Live! tech cert requires that you work well in multiplayer on 64 kbps upload. While some users may have 768 (DSL generally comes with 384), you're not allowed to use that in your normal multiplayer scneario.


#69 Gagyi   Members   -  Reputation: 192

Like
0Likes
Like

Posted 07 September 2009 - 10:23 AM

Hi guys, I'm the developer of the earlier mentioned Stickman Warfare, one of the banned guys from here has invited me to this topic, so I'm just here to share my experiences.

I've been doing stickman for like 3 years now, and i have to tell you, P2P is a heavy PITA. Not only it has sync and connect issues, it's really easily hacked. But the reason I made it this way is that its absolutely free to host, since a P2P NAT introducer doesn't use too much bandwidth OR CPU, so it can be run from a really cheap (free) virtual server at my friends computer.

Apart from the NAT stuff, i found P2P a lot easier than C/S. Simply because the player only has to care about his characters physics only, and it doesn't have to synchronize with the server, compensate the roundtrip time or anything like that. Only the priority system was a bit difficult/complicated until i fine tuned it. Now the network code is no more than a few thousand lines of PASCAL code.

Oh, and with the right priority system, you can have infinite players using only 7kBps upload. (yes, stickman did not lagg at 70 players and its completely scalable)

OF course, this cannot be applied to a commercial game because its so much less secure than C/S that hacking is inevitable, only delayable (memory protection, debugger detection, etc... but thats only against Cheatengine using script kiddies).

Well, thats all i could think of.

P.S: Its been a long time since i used my English...

EDIT: Forgot to mention, my P2P implementation is rather unstable, there are times when you don't connect to the clod or suffer severe lag. Thats completly my fault, not the P2P's.

EDIT2: I just read th whole topic, and I dont know the guy, please dont ban me :P. I dont consider my game great or innovative, it is just your average P2P shooter.
-----------------------------------"After you finish the first 90% of a project, you have to finish the other 90%." - Michael Abrashstickman.hu <=my game (please tell me your opinion about it)

#70 hplus0603   Moderators   -  Reputation: 4955

Like
0Likes
Like

Posted 07 September 2009 - 10:28 AM

Quote:
stickman did not lagg at 70 players and its completely scalable


What happens when 100 players all congretate in the same spot?

Quote:
stickman.hu <=my game (please tell me your opinion about it)


404


#71 Codeka   Members   -  Reputation: 1153

Like
0Likes
Like

Posted 07 September 2009 - 10:37 AM

Quote:
Original post by Gagyi
EDIT2: I just read th whole topic, and I dont know the guy, please dont ban me :P. I dont consider my game great or innovative, it is just your average P2P shooter.
Hehe, I don't think you have to worry. At least you have the benefit of having actually implemented your idea, rather than just spouting numbers and selectively quoting other people's work :-)
Quote:
Original post by Gagyi
But the reason I made it this way is that its absolutely free to host, since a P2P NAT introducer doesn't use too much bandwidth OR CPU, so it can be run from a really cheap (free) virtual server at my friends computer.
Yeah, I would say that's probably the biggest advantage for an indy developer.

#72 Codeka   Members   -  Reputation: 1153

Like
0Likes
Like

Posted 07 September 2009 - 03:25 PM

Quote:
Original post by Super-Sandra
Quote:
Original post by hplus0603
Quote:
There is a growing desire to use the machines of participants themselves rather than separate dedicated servers to provide resources for serving games.


Do you have any support at all for this statement?


In my browser I have a message, from yesterday, that is not here today. It was a summary from the paper answering questions posed by Codeka and Gaffer. It also answers your question.
I don't think that paper actually answers hplus0603's question. Certainly, the paper isn't a study of the desire to use the machines of participants themselves rather than separate dedicated servers, it just "assumes" that's what people are after.
Quote:
Original post by Super-Sandra
Quote:
Original post by Codeka
Where do you get the number 900 from? From the papers linked so far in this thread (and all the other papers I have found), it seems to me they're testing only 2 players at a time, with 30 bots (i.e. 32 players in a single game).

Quote:
Original post by Gaffer
The end result being you don't need such a high frequency of updates to get smooth realistic motion of players and AIs in the remote view - you can get away with something like one update per-second vs. the usual 10 or 20

(but then again, if I'm missing something let me know ... it's been a long while since I've read that paper)


Donnybrook: Enabling Large-Scale, High-Speed, Peer-to-Peer Games
Each player receives frequent updates, at a rate of 20 per second, from only five other players independent of game size. Guidance is sent to all players, but only once per second. Thus, while the mean bandwidth requirement per player still scales quadratically, it is reduced by a factor of approximately 20*n/20*5+n. For a 1,000-player game, this reduces the requirement from 12Mb/s to 670Kb/s, making such a game feasible.
670Kb/s is still unfeasable today.

Actually, there's nothing in Donnybrook that couldn't be implemented in a client/server application to reduce the bandwidth requirements on the server (so you'd still have O(1) upload bandwidth requirement on the client, and you can reduce the upload bandwidth requirements on the server [and download bandwidth requirements on the client as well] using Donnybrook).

You still have to calculate all the physics and such on the server, which might be a problem for a complex 1000-player world, but not impossible (besides, it's much easier to buy more/faster CPUs than it is to buy more network bandwidth)

In any case, my previous statement about the complexity of the implementation still stands as well...

#73 Hodgman   Moderators   -  Reputation: 27502

Like
0Likes
Like

Posted 07 September 2009 - 04:35 PM

Quote:
Original post by Antheus
This thread is a complete mess.
+1

Whetever little actual information is present in this thread has been ruined by the zealous nature of the "discussion" (if you can call "im right an you're wrong, so there" a discussion).


They're both appropriate in different situations. If you read descriptions from popular engines (e.g. the Half-life network overview) then they explain their decisions. Abaraba obviously hasn't read up on how exactly popular C/S is implemented in Source/Unreal/Quake, because he's pointing out flaws like "and even worse, they may itself be the source of another set of visual artifacts since they can easily mismatch with server’s next update" which are "solved" by the previously mentioned models (and, like most info in this thread, the same solutions could be applied to C/S or P2P...)


Furthermore, many networking models that are independent or the choice of C/S or P2P have been muddled in with either of these choices during the thread.
For example, the lock-step technique where the inputs of the simulation are shared and agreed upon in advance (the actual state is not shared) can be implemented in either C/S or P2P...

These models may be more useful to one system than the other though.
For example, lock-step fits in well with P2P as there is very little data shared between clients, however if for whatever reason the lock-step model will not work for your game, then that may sway your decision as to whether S/C or P2P is feasible or not.
E.g. if your game *requires* a huge amount of state to be broadcast, then limited client bandwidth might mean that your game simply doesn't work without a dedicated high bandwidth host.

Of course you can try do design games without steep requirements, but in the real world we deal with diverse requirements, and in the real world there are no silver bullets. There are however, decision trees, which can tell is which bullet is the silver one *for this particular situation*.


If something useful was to come out of this thread it might be some kind of flow-chart that shows in what situations S/C or P2P show their strengths and weaknesses...


e.g. if cheating is not a concern you may choose to have clients do hit-detection client side - this decision works in both S/C and P2P though! So now you've decided to run game logic client side, you can decide if clients broadcast to each other, or forward packets through a server. Perhaps they would even do a bit of both (low-bandwidth players using high-bandwidth players as a proxy).
Perhaps it's not possible to run much game logic client side, which would require an 'authority' (server or a peer). Perhaps in the case of a full authoritative server clients can still share their inputs P2P style for prediction.
There's obviously a multitude of ways that data can be shared, various places that data can be computed (with different levels of authority) and lots of techniques for replicating a simulation.

There is no one perfect answer for all situations! Anyone who says they've found the silver bullet is likely ignorant, inexperienced or is simply trolling.

[Edited by - Hodgman on September 7, 2009 10:35:13 PM]

#74 Ysaneya   Members   -  Reputation: 1235

Like
0Likes
Like

Posted 07 September 2009 - 10:12 PM

Quote:
Original post by Gagyi
Oh, and with the right priority system, you can have infinite players using only 7kBps upload. (yes, stickman did not lagg at 70 players and its completely scalable


The problem with abaraba is that he took your game as his main argument to demonstrate that P2P scales better than C/S.

Of course, this priority system could be equally implemented in a C/S model too, so there's nothing you can deduct from the fact that Stickman can handle 70 players at 7kBps, and certainly not that P2P > C/S.

Y.


#75 Gaffer   Members   -  Reputation: 422

Like
0Likes
Like

Posted 08 September 2009 - 08:31 AM

Quote:
Original post by Hodgman
Furthermore, many networking models that are independent or the choice of C/S or P2P have been muddled in with either of these choices during the thread.
For example, the lock-step technique where the inputs of the simulation are shared and agreed upon in advance (the actual state is not shared) can be implemented in either C/S or P2P...


agreed 100%, unfortunately abaraba got these things mixed up, glomming on the P2P topology and not considering the networking model - at first he opined that the age of empires networking model (lockstep) was the shining light demonstrating the virtues of P2P, later on he moved to stickman as his new beacon of light in the darkness...

of course, we all know these two games have *radically* different networking models, really i can't think of anything more different in treatment than an input/command based deterministic lockstep model vs. a state passing asynchronous model -- but try explaining that subtlety to a guy like abaraba.

Quote:
Original post by Hodgman
Whetever little actual information is present in this thread has been ruined by the zealous nature of the "discussion" (if you can call "im right an you're wrong, so there" a discussion).


If you read this thread and the other forum links on the internet where this guy has trolled, i'm sure you'll come to the same conclusion as we did - it's simply not possible to have a rational discussion with this guy.

http://gafferongames.com/2009/09/04/the-return-of-the-timestep-crusader/

He's been banned from just about every forum on the internet, and keeps coming back with aliases to further his discussion way past the point of no return. He was actually banned on this site *before* this thread even started, for doing exactly the same thing in two threads previously re. P2P. And yet, he keeps coming back to beat the dead horse in this thread :)

The problem with properly refuting his points and providing useful information is this guy just doesn't care or understand any points you make. Instead of considering the points and thinking about it - he'll immediately take any new information you provide and turn those around to advance the discussion towards his argument.

The only technique I've found that works is to simply refute his points without adding anything new to the discussion for him to "tangent" off, while clearly demonstrating that his original statement is false.

Quote:
Original post by Hodgman
There is no one perfect answer for all situations! Anyone who says they've found the silver bullet is likely ignorant, inexperienced or is simply trolling.


Amen.

#76 Gagyi   Members   -  Reputation: 192

Like
0Likes
Like

Posted 08 September 2009 - 08:42 AM

Quote:
Original post by hplus0603
What happens when 100 players all congretate in the same spot?


You're always priority-connected to the closest 10 people and simply-connected to the closest 50 and low priority-connected (less than 1 update per sec) to the others. So you don't actauuly see the other 100 or you see the lagging horribly, of course. But this is the problem with C/S too (see Orgrimmar in WoW).

And, of course, EVERY solution used for P2P can be used for C/S. Too bad the opposite is not true.

Lastly, C/S is a much better way to spread all the information between all the people. Think of 10 students trying to share their homework solutions with the others. with P2P, 90 letters are sent, with C/S (one of the 10 would be the "server"), only 18 letters are needed to be sent.

P.S.: But cloud computing is the trendy way to do stuff these days, so running the game logic on client side is quite reasonable if you're not concerned about cheating.

EDIT: By letters, I meant the envelopes. Whatever, too late, sorry.

[Edited by - Gagyi on September 10, 2009 3:42:28 PM]

#77 Ma-we-Te   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 08 September 2009 - 02:38 PM

Quote:
Original post by Gagyi
Quote:
Original post by hplus0603
What happens when 100 players all congretate in the same spot?


You're always priority-connected to the closest 10 people and simply-connected to the closest 50 and low priority-connected (less than 1 update per sec) to the others. So you don't actauuly see the other 100 or you see the lagging horribly, of course. But this is the problem with C/S too (see Orgrimmar in WoW).

And, of course, EVERY solution used for P2P can be used for C/S. Too bad the opposite is not true.

Lastly, C/S is a much better way to spread all the information between all the people. Think of 10 students trying to share their homework solutions with the others. with P2P, 90 letters are sent, with C/S (one of the 10 would be the "server"), only 18 letters are needed to be sent.

P.S.: But cloud computing is the trendy way to do stuff these days, so running the game logic on client side is quite reasonable if you're not concerned about cheating.


P2P, Step 1:
Each student sends 9 letters, 10*9 = 90 letters


C/S, Step 1:
Each student sends 1 letter to server (10th student), 1*9 = 9 letters
C/S, Step 2:
Server (has all letters) sends back 9 letters to 9 students, 9*9= 81 letters


90 letters need to be sent in either case. However, if maximum allowed bandwidth for all students was 1 letter per second, then P2P could share their homework in 9 seconds, while C/S would need 1 second for the 1st step and 81 seconds for the 2nd step. C/S model also exhibits additional latency due to longer packet trip, extra routing and information processing done by the server. P2P is very good for sharing and communication, file sharing, chat, signaling, distribution of tasks and resources, such as CPU load and bandwidth.


Run AI algorithm for all low-priority (far away) players and you will get "Donnybrook Stickman", handling even hundreds of players without any lag. This, of course, will not apply to any type of game, but for a frenetic FPS it should mostly pass unnoticed.


Any two peers have a server-client type of connection and this should make possible to apply solutions from C/S to any two peer in P2P independently. What C/S tricks you have found do not apply to P2P?


Your game is pretty cool. It works much better for me than Quake Live, or to be more precise Quake Live doesn't work for me at all, I get "disconnected" messages flashing every 5 seconds, game stops for a while then all players warp around while animation is trying to catch up with something that looks like super-fast forward.

I'm connected via Wi-Fi network and my bandwidth is pretty low - 200/50kbps. Does anyone know if this could be the reason for lag, and how much bandwidth a Quake game with 16 players need per client, both upload and download? Though, I'm lagging badly even on 1on1 duel.


Mark

#78 Hodgman   Moderators   -  Reputation: 27502

Like
0Likes
Like

Posted 08 September 2009 - 03:08 PM

Quote:
Original post by Ma-we-Te
It works much better for me than Quake Live, or to be more precise Quake Live doesn't work for me at all, I get "disconnected" messages flashing every 5 seconds, game stops for a while then all players warp around while animation is trying to catch up with something that looks like super-fast forward.

I'm connected via Wi-Fi network and my bandwidth is pretty low - 200/50kbps. Does anyone know if this could be the reason for lag, and how much bandwidth a Quake game with 16 players need per client, both upload and download? Though, I'm lagging badly even on 1on1 duel.
Quake 3's network model (which I assume is the same as Quake Live's) doesn't deal very well with high levels of packet loss. It deals with lost information by re-attaching it to the next packet, which means extended periods of packet loss can cause the next packets to become larger, which also might inrcease the chance they will be lost in transit...

IIRC quake doesn't need much bandwidth in ideal conditions - ~5kb/s combined up/down on the client I think (if you experience large amounts of loss, you may need more bandwidth to compensate though). Your problem is probably latency and packet loss related.

#79 Sirisian   Crossbones+   -  Reputation: 1635

Like
0Likes
Like

Posted 08 September 2009 - 03:32 PM

Quote:
Original post by Ma-we-Te
Quote:
Original post by Gagyi
Quote:
Original post by hplus0603
What happens when 100 players all congretate in the same spot?


You're always priority-connected to the closest 10 people and simply-connected to the closest 50 and low priority-connected (less than 1 update per sec) to the others. So you don't actauuly see the other 100 or you see the lagging horribly, of course. But this is the problem with C/S too (see Orgrimmar in WoW).

And, of course, EVERY solution used for P2P can be used for C/S. Too bad the opposite is not true.

Lastly, C/S is a much better way to spread all the information between all the people. Think of 10 students trying to share their homework solutions with the others. with P2P, 90 letters are sent, with C/S (one of the 10 would be the "server"), only 18 letters are needed to be sent.

P.S.: But cloud computing is the trendy way to do stuff these days, so running the game logic on client side is quite reasonable if you're not concerned about cheating.


P2P, Step 1:
Each student sends 9 letters, 10*9 = 90 letters


C/S, Step 1:
Each student sends 1 letter to server (10th student), 1*9 = 9 letters
C/S, Step 2:
Server (has all letters) sends back 9 letters to 9 students, 9*9= 81 letters


90 letters need to be sent in either case. However, if maximum allowed bandwidth for all students was 1 letter per second, then P2P could share their homework in 9 seconds, while C/S would need 1 second for the 1st step and 81 seconds for the 2nd step. C/S model also exhibits additional latency due to longer packet trip, extra routing and information processing done by the server.

That's a big if. The way your treating "letters" is a bit odd. The server would batch send them, but given your interesting restriction of 1 letter then P2P appears better for that situation.

Quote:
Original post by Ma-we-Te
P2P is very good for sharing and communication, file sharing, chat, signaling, distribution of tasks and resources, such as CPU load and bandwidth.

Sure, file sharing with a middle man would be awkward. Communication (I assume you don't mean chat since you listed that?) might not work as well. There's something special that happens in VOIP. The server can take in all the data and merge the voices and such into 1 signal thus the server is only sending out 1 signal per person. (Or so I imagine). Chat like IRC is handled via a server. It's very low bandwidth, but yeah P2P could work especially for just 2 people.

#80 Antheus   Members   -  Reputation: 2393

Like
0Likes
Like

Posted 08 September 2009 - 07:39 PM

Quote:
Original post by Ma-we-Te
C/S, Step 2:
Server (has all letters) sends back 9 letters to 9 students, 9*9= 81 letters


In C/S model, the server takes 9 letters intended for the user, and rewrites just the summary into a single letter. So instead of sending 9, it sends only 1, which might be twice as long as any individual letter.

This is trivial and completely straightforward to do with C/S model. Similar is possible with P2P, but is much more difficult to get right.

Even without rewriting, server would open all 9 letters, and put them in single envelope. So instead of sending 9 envelopes and 9 letters, it's just 1 envelope and 9 letters, cutting postage costs in half.

Quote:
P2P is very good for sharing and communication, file sharing, chat, signaling, distribution of tasks and resources, such as CPU load and bandwidth


P2P is more awesome than Chuck Norris....

Why don't chat and IM apps use P2P then?
Signalling around here is done with traffic lights, not sure where P2P applies.
File sharing are one-to-one transfers, not one-to-many or many-to-many.
Distributing of tasks uses many different concepts, but most of them rely on some form of scheduler or task coordinator (possibly more than one), which is basically a server.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS