I have a few question about socket in c++!
First question, let's say that he writes a server for the game in which he will play 200 people at once, but accept is blocked because he already serves one client, how to deal with it?
Second question, how to download a list of all currently connected clients, so that you can then send a message to everyone?
I have a few question about socket in c++!
For future reference, please post only one question at a time. If you have multiple questions, post them separately.
let's say that he writes a server for the game in which he will play 200 people at once, but accept is blocked because he already serves one client, how to deal with it?
Use sockets in non-blocking mode, using select()/(e)poll() or other callback mechanisms to know which sockets have pending activity and when.
Otherwise, use accept() in a separate thread than other thread(s) used to service connected clients.
how to download a list of all currently connected clients, so that you can then send a message to everyone?
The server is responsible for keeping track of its connected clients. Then it can loop through that list when needed.
If a client wants to send a message to every other client, the best option is for it to send a single message to the server and ask the server to relay the message to every other client.
Otherwise, the client would have to request the list from the server, and then send a message to every other client individually.
Related
i'm having some sync trouble with threads and sockets. I need one thread to recive incoming connections on socket (and remember client data to respond) and other thread to setup frames and send current frame to listed clients. So i was wondering if its possible to (kinda) put my data frames into server socket, so that everyone could just read current frame from socket without server knowing.
Server will just spam its socket with some data and client will get data without server actions. Is this possible? how?
I'm currently doing it pretty messed up way which i dont like:
server is listening on one thread for incoming transmissions and upon reciving such, add client data to list.
on other thread server is sending data to all clients from list.
EDIT:
I want to send data to some kind of buffer from which clients are allowed to read. (client doesnt have to read all messages server sends, just the one buffer contains at the moment of clients request), i dont want server to even notice that clients are reading from buffer if possible.
Right now threads are syncronised using uniqe_lock
What you're describing is probably MultiCast. Specifically, IP MultiCast (I think).
Searching finds a number of useful resources. This one looks concise, and includes coded examples (although I'm not sure how current it is).
If you're only transmitting to a LAN then broadcast will work too.
I have a server interacting with multiple clients where the client send messages to the server and the server reads them via recv() method. The problem I getting is that Im using waitforsingleobject(handler, 10000 millisecs) in order to make the server wait for a few seconds to interact with one client and then let others access to it but then I start seeing answer from the server with the wrong message to the client and getting blocked. So looks like a synchronization issue.
So my question is (since I'm a begginer in c++) how could I ensure that every incoming message is received and replied to the right client, allowing all the clients interact with the server.
There're two alternatives.
First is a pretty standard model - one thread per one client. When a client connects, you start a thread to handle it.
Second approach doesn't require many threads. You should use WSARecv() on an overlapped socket instead of recv(). This way, you can simultaneously open multiple receive operations, one per client, and wait them all in a WaitForMultipleObjects(). To be specific, you will wait on event inside WSAOVERLAPPED. Remember that WaitForMultipleObjects() has a limit on number of wait objects. When exceeded, you will need to run another thread. The return code from WaitForMultipleObjects() will tell you which client has sent data, so you can reply to it.
Or, as suggested above, you could probably use select() to figure out which socket has data.
If I have a UDP server that handles incoming requests with recvfrom, processes the requests that come in (possibly time consuming), possibly sends back a response, and then calls recvfrom again, is it better to create a new sock_fd with the information in sockaddr* from to send the response back with or to use the server's sock_fd to send a response?
Basically, the question is do I want the overhead of having to create a new sock_fd, or do I want my server to be able to handle requests without having to wait to send the previous request a response.
I can't decide based on the application's needs, because this will be used in a library (hence I don't know whether there will need to be a response or not, and how long it will take to process the request).
I fail to see how this is not a real question. The question is clearly asked in the bolded section above, and in the last part of the first sentence
There is no need to create a new sock_fd as the one which is created will have already done a bind call as its a server.
Also you have to ensure that the clients are not waiting for a response in a blocking recvfrom .
Most servers send out some error codes if they cannot give a proper response and the clients do a repeat request or something depending on that error code, may be you need to design the protocol in request-response way.
If processing is a problem hen you can always have the data + struct sockaddr of client in a queue and defer processing by signalling a thread to wakeup, by doing so your listening thread can come back to recvfrom fast, and then you can send the response from the processing thread to the saved struct sockaddr of client when you are finished.
do I want the overhead of having to create a new sock_fd
No.
or do I want my server to be able to handle requests without having to wait to send the previous request a response.
Nobody has to wait to send a message over a UDP socket. You can handle every incoming request on a separate thread if you like, and they can all call sendmsg(), simultaneously if necessary.
You definitely only want to use one socket. For one thing, it will mean that the reply will get back to the client with the same source-address information that they sent it to, which will be less confusing all round.
I am pretty new to socket programming - so this might be a simple question but I'd really like to clarify.
I have a multiple-client to single server program: the individual clients send messages to the server which processes them, and then passes it on the destination i.e. the server is an intermediary.
On the server side, there is one thread for each client which is meant to 'listen' for messages from the clients (which will be placed in a buffer). At the moment all the clients are sending messages to the same port (as far as I can tell).
I am thinking of setting up another thread on which the server will process the messages before transmitting them on. Does it make sense to use another port on the server to send those messages?
I don't mean this to be a discussion, but I don't know what is common or more logical to do - any advice?
On the client-side, I am planning for it to have one thread for sending messages to the server, and another thread for receiving. Please let me know if any other information is required!
edit
At the moment it is a 1-server-to-multiple(tens now, hundreds later)-client program - I seem to have problems with the client receiving messages from my server (I am troubleshooting so I thought that using the same ports might be the problem), but I will try it with the same ports again and see. I thought it might be a matter of the receiving port being too busy to send messages as well.
At the moment all the clients are sending messages to the same port (as far as I can tell).
What do you mean 'as far as I can tell'? You must know whether you are opening more than one port at the server.
Does it make sense to use another port on the server to send those messages?
No it doesn't. If you're using TCP, send the messages back down the same socket. If you're using UDP you don't need more than one UDP socket, and it simplifies the client and the application protocol if replies come from the same ip:port the request was sent from.
I currently have a basic chat program in c++ that uses WinSock2.h with UDP. Currently the user is able to send a message to the server and the server just sends the same message back. I was wondering where do I go from here (i'm not asking for code). I was wondering how I should go forward in having the messages get sent to another client that is also connected to the server.
If I need to explain what I have done already please let me know.
All suggestions are greatly appreciated.
Thanks
You would have a list of currently connected users, when a user sends a message, it would then post it to all connected users.
Your server would keep track of who is connected, and remove those who get disconnected. When someone connect or disconnects, it would send a notification to all currently connected users, telling them of this notification.
All this is not specific to UDP, infact, TCP would probably be better for this type of messaging as you do not have to worry about messages being dropped. UDP should only be used where performance is of upmost importance, like real-time gaming, voice chat.
When you're saying "connected" (in the context of clients) - what exactly do you mean?? Because you say you're using UDP in your program.
In the UDP protocol there's no "connected" state, unless you implement it.
In the TCP protocol however, there is (implemented within the protocol itself).
Furthermore, the basic idea of "broadcasting" a message is simple - keep a list of connected clients.
Add a client when it connects. Remove it from the list when it disconnects.
Then when you want to send a message to everyone you just iterate through this list.
Again, you'll have to receive those dis/connect events before you could keep track of "connected" clients.
If you go with TCP instead of UDP then you're set.
Good luck.
Basically, like Matthew said, you need to store all the current connections to the server. When a socket connects you can store a reference to that socket. Now whenever a client sends a message you can rebroadcast that to all the sockets. Now you have to handle when sockets disconnect as well since you don't want to store a bunch of closed sockets.