Keep a list of all connected clients which you populate as clients connect. If you need to download it from the server , one  popular format is json

If you are using UDP, then there is no waiting for accept; you'll just read packets off the socket and look at the returned remote address to see which peer sent the message.

If you are using TCP, then accept() will block if there is no client ready to accept. Therefore, you have to include the listening socket, as well as each client socket, in the set of sockets you pass to select() to be able to tell whether it's safe to accept() a client or not without blocking. select() will also tell you which other users have data that you can recv() without blocking. There are tons of tutorials on how to use socket()/listen()/select()/accept()/recv()/send() to implement a proper TCP socket server.

You do not want to send the IP address of each other client to each other client, for two reasons:

1. It exposes the IP address of other players to other players, which lets other players launch DDoS attacks against them
2. You won't be able to connect through each of the other players' firewall, unless they have set up port forwarding

This is why you use a server: You send the message to the server, and the server forwards the message to the other players that need to see it.

If you use UDP, you can implement something called "NAT punch-through," which uses the original server as an introducer that lets you get through the firewall in 90% of cases. However, that doesn't work particularly well with TCP, and you typically only use this to let players "host" games as player-run servers, rather than using this for every player to find every other player. (Peer-to-peer star topologies do not behave well as they scale up.)