Oh, and your website HTTP://www.NYNInteractive.cjb.net is apparently down by the way.....

Yeah, the site could be down, I just moved it to a new server. Anyhow, since I started college its severely out of date so you''re not missing much anyhow

Anyhow, back to the question at hand...

By using UDP for chat, you are not connecting (in the networking sense of the word) to multiple people. You simply have a socket where you can direct messages to multiple different targets. Had you been using TCP, you would need to form a specific connection to each host, each on a seperate socket (this is what I assumed you were talking about). Basically what you have is two types of communication going on, client-client and client-server. Its certainly ok to seperate those two types into multiple sockets, just don''t go overboard. Perhaps simply seperate them logically into a handfull of sockets, each for a specific task or related group of tasks. 100-150 sockets is too many, IMHO, I doubt that I would personally use any more than 10 or 12 for this type of application. However, I don''t know your full design and your implementation is up to you.

On another note, the idea of sending your avatar''s appearance is also OK to broadcast, it may not save all that much bandwidth though. I would disagree with the clients sending their guild/clan icons to each other though. For example, if this icon is used for clan-identification purposes, I could see cheaters altering their icon into a sort of trojan horse, gaining them access to another guild/clan where they may steal, sabatoge or worse.

Anyhow, I hope my critisism is constructive, I''m not trying to knock you at all, just helping you see all the angles. It''s nice to see that someone is actually thinking about the issues of multi-player games before screaming about their new MMPOG.

Ravyne
Owner/Lead Programmer & Designer
NYN Interactive Entertainment
HTTP://www.NYNInteractive.cjb.net

quote:

---

Original post by Ravyne
For example, if this icon is used for clan-identification purposes, I could see cheaters altering their icon into a sort of trojan horse, gaining them access to another guild/clan where they may steal, sabatoge or worse.

---

Wow; this sort of misinformation might be an excellent gameplay feature. Imagine a player neglecting to attack an impersonator posing to be a member of the same guild in a battle, a spy sent on an espionage mission, or an assassin hired by a rival guild who manages to slip through primary defenses due to this icon. If icon manipulation became widespread, guild members would be forced to form stronger relationships amongst each other as trust would no longer be based simply upon outside appearance. The game may become much more interesting and involved as a result.

If this is desirable, you might not have to force peers to send actual graphical data to each other; your game might force guild leaders to register their guild with the server upon creation. Registration would include an option to upload an icon representing the guild. During login, the client would query the server for a listing of guilds created and disbanded since the client''s last login. If the client is completely new to the game, the server would post a list of all current guilds. The client would proceed to download icons representing the guilds from the server at its leisure (or, if storage capacity is a concern, the server might store web addresses and the client would download the icon from an outside web site using HTTP requests). If an icon downloaded during a previous login represents a presently-disbanded guild, the client would delete the icon from its data files. After downloading the relevant icons, the client would then establish peer connections and truly enter the game. When a peer approaches, the peer tells the client which guild/icon to display, completing the effect with little peer to peer bandwidth consumed.

________________________________________________
RapscallionGL development continues...
"Optimal decisions, once made, do not need to be changed." - Robert Sedgewick, Algorithms in C

Guys, you are missing the whole point of why this will not work in most applications, and why it should not be used ( especialy on a Windows machine ). Having 50 to 150 open, bound, and active sockets on a client just is not a reality for most machines.

First, for every socket that is open and bound, a part of the non-pageable memory is consumed. The higher you get, the more likely you are to cause a rather nasty crash.

Seconly, you are still polling those 50 - 150 sockets for data, which *will* eat up all of your CPU time ( especialy if you had planned on having a seperate thread for each one, as that is a common mistake for first attempts ).

Finaly, I do kinda like the idea. I have reservations about letting any client realize that there is such a thing as another client, but that''s just me. If you want to implement this, do the odvious: Use a single socket. Simply keep a list of the IP \ Port of each peer that you need to update when you talk, ect. and simply use sendto() or WSASendTo(). This will not have a negative impact on preformance, and by only polling one socket for p2p data, it frees up a *lot* of CPU time ( especialy if you are using blocking I\O ).

Hope that helps.
Q

I agree that one hundred fifty active sockets managed by a single application does seem excessive, but I feel some of the above points have been overblown:

quote:

---

Original post by QBRADQ
Guys, you are missing the whole point of why this will not work in most applications, and why it should not be used ( especialy on a Windows machine ).

---

I''m just curious here. Is there a particular reason machines running Windows operating systems are less apt to handle this kind of load?

quote:

---

First, for every socket that is open and bound, a part of the non-pageable memory is consumed. The higher you get, the more likely you are to cause a rather nasty crash.

---

Approximately one quarter of physical memory (RAM) is set aside for the non-paged memory pool within Windows operating systems. Connected sockets use about two kilobytes of memory from the non-paged pool.

Now, let''s run some numbers. My laptop currently enjoys 256 MB of physical memory, meaning up to 64 MB of memory may be set aside for the non-paged memory pool. Let''s suppose that kernel operations require 10 MB of non-paged memory. Other applications require 22 MB of non-paged memory; apparently, the other applications are quite fond of locking data into physical memory. We are left with 32 MB of available memory in the pool for use by the original poster''s program. Considering we have one hundred fifty connected sockets all consuming two kilobytes each, we see that a mere 300 KB of non-paged memory is required. That''s 0.92% of the remaining available memory--in other words, barely noticeable.

In all, depleting the non-paged memory pool does not become a real concern until rather high performance server applications are considered. The above analysis did not discuss actual data throughput, but, if consumed bandwidth remains under the maximum imposed by a 56 Kb/s connection as PaulCesar asserts, data buffering requirements do not substantially tax the non-paged pool.

quote:

---

Seconly, you are still polling those 50 - 150 sockets for data, which *will* eat up all of your CPU time ( especialy if you had planned on having a seperate thread for each one, as that is a common mistake for first attempts ).

---

Not necessarily; though spawning a thread for each of the one hundred fifty sockets would most likely be unacceptable for a client machine, CPU usage could be tamed by allowing the sockets to inform the application of a network event rather than vice versa. Asynchronous sockets coupled with event objects might be the best approach here if PaulCesar continues with the multiple peer connection framework and does not turn completely to UDP.

________________________________________________
RapscallionGL development continues...
"Optimal decisions, once made, do not need to be changed." - Robert Sedgewick, Algorithms in C

OMG, another thread about to derail...

quote:

---

Guys, you are missing the whole point of why this will not work in most applications, and why it should not be used

---

No, I think I hit it right on the head in my initial response. Security in any type of community-based game (i.e. MMO) is paramount. This distribution of server responsibilities to the clients is silly regardless of whether you are using TCP or UDP. Don''t dismiss the community-destroying effects that misuse/abuse of something as "simple" as Chat can have on your game. The idea will probably work, technically, but it isn''t practical.

quote:

---

from QBRADQ do the odvious: Use a single socket. Simply keep a list of the IP \ Port of each peer that you need to update when you talk, ect. and simply use sendto() or WSASendTo(). This will not have a negative impact on preformance, and by only polling one socket for p2p data, it frees up a *lot* of CPU time ( especialy if you are using blocking I\O ).

---

For the uninitiated, he''s saying to use UDP. Good idea. I can''t imagine why anyone would want to try this with TCP.

quote:

---

QBRADQ ...it should not be used ( especialy on a Windows machine )

---

In 99.9% of commercial games the default client platform is Windows. So at the very least your network library will have to support Windows anyways.

quote:

---

johnnie2 Is there a particular reason machines running Windows operating systems are less apt to handle this kind of load?

---

Actually, you guys should be more specific when you say "Windows", because most people posting here are probably not using a Windows OS that was intended as a server platform. The latest Windows systems(Win2K/2K3) do fine under load, usually. It''s cost that I''d be more concerned about with those.

quote:

---

by Anonymous Coward OMG, another thread about to derail...

---

OMG, another thread that actually contains discussion about the given topic *gasp*.