Using package scheme in different languages ...

[NoHero]

I need this for my school project. I have to write an Client/Server application that should act as a Chat (with rooms, user groups and such stuff) and I read through the code guru articles refering to network programing, such as this:
http://www.codeguru.com/forum/showthread.php?t=306399

There are now two ways for me to introduce the internal chat server protocol:

* I use plain text commands
or
* I use the package scheme.

I prefer the second solution but:
My question now is, if I introduce this packet scheme in my C++ written server, can a Java or a Delphi written client understand these packages? If yes what do I have to consider? Or should I write an C++ layer (a dll for example) that lies under the Client itself, and the client is just using these functions?

Any tip or help would be very appreciated.
Thanks in advance
Florian

[j0nas]

Design your app in different layers. For instance, the API/class for the Chat-client, should be independant of the actual network scheme (transport). With that you could use different backends for the actual data transport.

A more light-weight method could be to really focus on the protocol design. A good protocol specification can be used as an external interface for other implementations (in Java, VB, C etc etc).

Of course, if you combine both these: a good network protocol and a solid, modular design of the client/server programs... then you're home.

Maybe you shouldn't over-do it (don't know how much time you have). I would go for a nice text-based protocol and let the protocol be the external interface. Text-based protocols are good because you don't need to deal with machine byte-order and formats on binary values.

One drawback with text-based protocols are for instance the large file transfers. You need to encode binary data (such as files) with base64 (or some other text-method) and that will increase the size with 33 % on the wire. There is a solution for the file transfer problem: switch to binary mode during file transfer.

[NoHero]

Thanks for you reply.

I really take of this project, because its a school project, so I want it to become something good.

I have a lot of time (4 months, we are also 2 people who are working together), so it would not be a problem making it big but good. So you think text mode would be perfect? ... Because I do not have to send files (It's just a chat client/server for plain text messages, or rtf texts). I also thought about the best way to implement a server:

* Should I create a thread for each client? (Max. Number of clients expected: 300)
* Should I implement a queue where I queue the requests. And the server just picks one, processes it and picks the next?

Regards, Florian

[j0nas]

Yes, a text protocol would be my choice.

I can't say I'm an expert on server programming, but here are my recommendations: (on a TCP socket server)
1. Implement a (stateless) request-respone protocol over TCP
2. Implement statefulness (if needed) using server cookies (opaque blobs)
3. Don't build a 100 % online system (server should be able to close a socket/connection after some idle time, the client can later resume the connection)
4. Don't use one thread per socket (too much overhead)
5. Be nice to TCP and close the socket gracefully, you may otherwise run out of socket resoures on the server (TCP wait states)

A request queue sounds good, but be sure you design it as simple as possible (but no simpler). If you create a fancy thread pool etc, be sure you understand how to protect shared resources (the socket for instance).

Also, give some early thoughts on data and enities... (answer questions like: what is a user? how are users represented/identified in the system? etc etc)

One last thing: Don't be afraid to "borrow" design from other successful internet application protocols.

[NoHero]

Yes, a text protocol would be my choice.

I can't say I'm an expert on server programming, but here are my recommendations: (on a TCP socket server)
1. Implement a (stateless) request-respone protocol over TCP
2. Implement statefulness (if needed) using server cookies (opaque blobs)
3. Don't build a 100 % online system (server should be able to close a socket/connection after some idle time, the client can later resume the connection)
4. Don't use one thread per socket (too much overhead)
5. Be nice to TCP and close the socket gracefully, you may otherwise run out of socket resoures on the server (TCP wait states)

A request queue sounds good, but be sure you design it as simple as possible (but no simpler). If you create a fancy thread pool etc, be sure you understand how to protect shared resources (the socket for instance).

Also, give some early thoughts on data and enities... (answer questions like: what is a user? how are users represented/identified in the system? etc etc)

One last thing: Don't be afraid to "borrow" design from other successful internet application protocols.

Thanks a lot ...

@Entities: We have worked out the 3th normal form of your set of entities with our Advanced Data Engineering professor. Our concept and our scheme is ready and good :thumb:

[Mathew Joy]

One comment about the no of threads. If going for one thread per client, 300 threads could be a lot, but even under full load, for your chat based server not more than 50 threads will be active at a given time. And not many times will you see your server under full load. So one thread per client won’t be a bad idea…it is a lot simpler. You can have a thread pool with the threads in a wait state (sleeping, taking no processor power). Once the clients are connected each thread could be assigned a socket. The no of thread to be created in the pool could be arrived after a testing under simulation.

[NoHero]

One comment about the no of threads. If going for one thread per client, 300 threads could be a lot, but even under full load, for your chat based server not more than 50 threads will be active at a given time. And not many times will you see your server under full load. So one thread per client won’t be a bad idea…it is a lot simpler. You can have a thread pool with the threads in a wait state (sleeping, taking no processor power). Once the clients are connected each thread could be assigned a socket. The no of thread to be created in the pool could be arrived after a testing under simulation.

Sounds quite interesting though. But the major problem I'll have is that I have no expierences with thread pools etc. I implemented the basic structure today: I have one thread that sleeps until the server adds requests to the queue. If the all requests are handled, the thread is going back to idle mode. Is that a good solution?

Regards nohero

[Mathew Joy]

Any solution is good if the server is low load. Request queues are ok for your server. If you have already begun to implement it, then go ahead with that.

Thread pools can be simple or complex to manage. A simple one can be a group of threads waiting for an event (you can use Events for that. Look for CreateEvent() and co.) to happen. One of the threads will get the signal and process the request. If any other request comes one of the other threads will handle it. The optimum number of threads to be in the pool can be based on the utilization of CPU on good load. If it is less, that means you need more threads. For a chat server of your kind I think 2 or 3 will be enough. The no. of threads also depend on whether the threads will be doing any IO. More IO, more threads will be required.

[NoHero]

Any solution is good if the server is low load. Request queues are ok for your server. If you have already begun to implement it, then go ahead with that.

Thread pools can be simple or complex to manage. A simple one can be a group of threads waiting for an event (you can use Events for that. Look for CreateEvent() and co.) to happen. One of the threads will get the signal and process the request. If any other request comes one of the other threads will handle it. The optimum number of threads to be in the pool can be based on the utilization of CPU on good load. If it is less, that means you need more threads. For a chat server of your kind I think 2 or 3 will be enough. The no. of threads also depend on whether the threads will be doing any IO. More IO, more threads will be required.

I don't really have to make I/O operations, I just give the message package to each other user in the room. Or perform simple task's like move user to another room that are just a few lines of code. So I think a thread pool does not really make sense.

[Mathew Joy]

I don't really have to make I/O operations, I just give the message package to each other user in the room.
And what do you suppose that is? :rolleyes:

[NoHero]

And what do you suppose that is? :rolleyes:

Yes, but I do not expect all 300 users to be in one room. Because there are read/write rights the users have.