What I mean is, if I have only one socket, can I both send and recieve on it at the same time? I''m thinking not and am planning to create an incoming socket and an outgoing socket so that i can have separate threads handle each one. Server might have multiples of both but the client will only need one of each as I see it. Server might not need more than one either. Depends on just how much info can be read/sent on a single socket. Though i''m betting that MMO amounts of traffic will be too much for just a single socket to handle. Thanks, Webby

You can send and receive on the same connected socket but, as you said, you might want to have one for each.

I can''t comment on the MMO part, but sockets are read/write for both client and server.

Sockets are full-duplex depending on your definition of terms, of course.

Also, the practicality of such a thing depends on the I/O model that you use. If you do some form of multiplexing, then you can get around the blocking nature of sockets, etc.


.zfod

It''s quite a waste to have two sockets... Sockets are byte streams, just like files, you can read and write at the same time.

Plus, a sending thread isn''t such a good idea, because of the big overhead of starting a thread when you want to send... You might just immediatly send.... Since that doesn''t block.

"Though i''m betting that MMO amounts of traffic will be too much for just a single socket to handle."

What difference does it make, wether you use one or two sockets? If you use two, thats just one more socket for the OS to take care of... And things work the same, whatever socket you send/receive on. In the end, the only thing that makes a difference is how efficient your hardware and operating system are.

Hmm,

Well, web browsers certainly make use of threads making socket connections to send data.

Like anything, it depends on what you''re doing that will make or break what sort of model you want to use.

Threads on the server-side? Sure, if you can deal with the synchronization issues, thread-safe calls, etc. Threading is usually much better than invoking another heavy process.. but it depends on what thread library you''re using as well as the OS.

Using a server-side thread pool has worked quite well for me, in the regard of the general nature of this forum topic.

YMMV of course,

.zfod

> if I have only one socket, can I both send and recieve on it at the same time?

Yes. Make sure you have Winsock 2 or better otherwise ''select()'' will not work properly if you have separate threads for read and write.

> Though i''m betting that MMO amounts of traffic will be
> too much for just a single socket to handle.

A socket is just an OS abstraction; doubling the number of sockets won''t double your network throughput (nor will 100 sockets suddently make your network card''s performance jump from 10Mbs to 1000Mbs). Though you may want to separate the login socket from the data exchange socket for security reasons.

-cb

That makes sense.
I was thinking that it might work just like a file. For example, if I have file A and I try to write to the file and at the same time I try to read from the file then the 2 operations would potentially overlap and while the write would probably work just fine, there''s no guarantee that the data I read would be correct. It could be part old data and part new data from the present write operation. That is, unless the OS controls simultaneous operations on a file (puts them in sequence through file locking or some other same memory procedure).

Thanks though.
The client shall have only 1 socket. Still going to create a thread for recvs and a threads for sends because I plan to just let them block until something is there. I think that would by far be the fastest model for the client.

Still haven''t decided for the server yet though a single socket again seems like the appropriate choice since it''s all handled by the hardware anyway.

For that I am thinking of a single thread to recieve packets from the socket and simply store them in my own buffer where I handle them later. Then multiple threads to actually handle to packets from my buffers (probably a single thread per unique packet type so that the threads won''t often have to wait for each other to finish thereby limiting the need for mutexes and thread synchrinization). Probably something like one thread to handle chat packets, one to handle player battle commands, etc.

Sending packets back to the clients I''m not so sure. I''d need a way to send to as many clients as possibe, as fast as possible so I''d probably be better off there with multiple threads again. Possibly a send thread for the different types of packets needing to be sent.

Any thoughts?

Thanks, Webby

quote:

---

Well, web browsers certainly make use of threads making socket connections to send data.

---

And web surfing, as well all know, is dog-ass slow... pardon the expression. High performance is neither required, nor expected. An MMO would be an entirely different story.

quote:

---

If you do some form of multiplexing, then you can get around the blocking nature of sockets, etc.

---

Or you can use a non-blocking socket (probably best since he''s talking about using UDP).

quote:

---

Threading is usually much better than invoking another heavy process..

---

Yes, in most systems context switching a process is more expensive than context switching threads. But what if the process is running on a completely different system? The beauty of using multiple processes instead of spinning off threads is scalability and relocatability.

quote:

---

For example, if I have file A and I try to write to the file and at the same time I try to read from the file then the 2 operations would potentially overlap and while the write would probably work just fine, there''s no guarantee that the data I read would be correct.

---

Sockets have two seperate buffers, one for send, one for receive. They are completely independent at the application level. You can increase the size of those buffers as well. There is no need to use multiple UDP sockets on either client or server.

quote:

---

Sending packets back to the clients I''m not so sure. I''d need a way to send to as many clients as possibe, as fast as possible so I''d probably be better off there with multiple threads again. Possibly a send thread for the different types of packets needing to be sent.

---

You are probably not going to get the kind of performance increases you expect. Keep in mind that all of those threads don''t really run at the same time... even with additional CPUs you will never see a linear increase in performance.

quote:

---

Plus, a sending thread isn''t such a good idea, because of the big overhead of starting a thread when you want to send... You might just immediatly send.... Since that doesn''t block.

---

I don''t think he means start a new thread everytime he wants to call sendto(). I think he means having a persistent thread running to handle sends. But I agree, this isn''t necessary, whether it''s a turn-based RPG or a MMO.

The concerns about the amount of data generated in a MMO are certainly valid, and it''s a very real issue that has been solved commercially in a number of ways. Compromising a solid design by spinning off tons of threads in your network code is not necessary to achieve high data throughput.

OK. Not talking about tons of threads :0
Here is a base design that I have in mind as of right now.

ThreadA: This thread is passed a function that does nothing but continuously reads the socket for an incoming packet. When a packet arrives then this thread/function reads in the packet and stores it onto a serverside data structure.

ThreadB: This thread pops a packet from the top of my serverside packet holder and processes it. By processing it I mean that it will first determine what kind of packet it is and then send that packet on the the actual thread that handles that kind of packet.

ThreadC: This thread executes a function that simply waits for a packet to be sent. When received, the thread will send the packet through the socket to the other side. It does nothing more than wait for a packet and then send it when it gets one.

ThreadsD-XXX: These will handle packet types. Not individual packet types but more like one thread to handle all chat packets. One thread to handle all movement_request packets. One thread to handle all inventory_specific packets.
This gets broken down however far I feel necessary but probably not very deep.

Ideally, I want the threads to have as little data in common as possible. So a chat thread is fine because chatting won''t require the accessing on any game specific memory.

A movement thread will handle player positions and as such won''t worry about player inventories, battle messages, etc.

This is the kind of design I am working on ATM. I have coded nothing as of yet because I''m still working on design issues, like whether or not this will work. My reasons for using threads are multi-fold. 1) I am planning for quad processor machines minimum for the world servers so 4 threads minimum to utilize all processors. 2) The overall code structure seems well adapted to the use of threads or at least processes because in a MMO there are many concurrent things happening that are often not related at all. To me that just screams "THREAD ME" or "FORK ME"

You mention scalability and relocatability. My thoughts on this fall into some of the above. The way I am designing, if I can''t get a clear cut reason for a separate thread then I do not creat one. I have to have a specific goal that is both large enough and can process independently of all other operations to justify making a thread for it. Because of this design, if I later opt to move some of the logic to another computer (like AI for example) then it will be a simple thing to extract the code for the AI and work up another server specifically for it.

At this point I''m thinking of threads being more like objects that do their own complete thing. There is a word for functions that are too related in the processing that they do, I think it''s called cohesion? Or maybe coupling? Can''t remember but I know it''s a bad thing in a program.

So if I build around this OO point of view then everything should be OK with regards to relocatability and scalability.

All in all I can right now think of a use for at most 8 specific threads. I''m sure others may pop up but I am very much a tightwad when it comes to allowing for extra threads in my design simply because I like the KISS method. In this case however, threading just make more sense than not.

Thanks for all the great advice. Please keep poking holes in the weak spots because I''m sure there are many. I''m tightening the design up every day.

Webby