so that socket can receive data from everywhere

If I have a server with that socket and I am recieving data from different clients

Is it better in performance to create the same number of sockets to clients?

I mean as the server identifies that data has come from a new client it will create a new socket, and if data doens't comes from a client after 1 minute the server will delete a socket.

I'm just taking a guess here: I think performace would not be the problem, It's possible however that lots of clients sending to the same socket can fill up the receive buffer if the server can not process datagrams fast enough. On the other hand, Opening more sockets would not solve that problem either. Maybe someone with more experience can answer.

You should probably do the simplest thing which can possibly work and work on performance later.

Use a single socket. In practice it is generally easier to work with fewer sockets (i.e. just 1) rather than lots. You can easily multiplex many clients on a single socket by just processing packets as they arrive.

However, you should still consider using TCP as it solves a lot of problems for you and might be ok, depending on what kind of game you are making.

This is not so much a question about whether one or the other is more efficient, but about how things work.

If you are using UDP, then you will only have one socket (unless you plan to have every client use a different port, which would be kind of a weird design).

If you are using TCP, then you will have one listening socket, plus one socket per client that connects. It simply isn't possible to do something different.

Whether you use one or the other depends mainly on whether or not you can answer one question with "yes": "Do you need your data with as little delay as possible, and is it possible to ignore missing packets?" If the answer is "yes", you want UDP. If you are not sure or the answer is "no", stop thinking about UDP, you want TCP.

TCP works perfectly well and is not any "slower" than UDP. They perform exactly identical 99% of the time, but TCP is easier to use, as it emulates stream of data and is reliable, much as if you read from a file. The only time at which they differ (in their performance characteristics) is when packets are lost. TCP will wait for a short while and resend packets when no ACK comes in, and the other end will wait until the data has arrived in the correct order. Insofar, TCP works contrary to how IP (the protocol both TCP and UDP build on) works -- UDP on the other hand works exactly like IP. UDP will try to deliver each packet you send, but if it doesn't arrive, that's just bad luck for you. If you can live with this, it's perfect. If you can't live with that, you want TCP (it's possible to implement reliability on top of UDP too, but that's not trivial to do, and easy to get wrong, and it will not perform any better (though possibly worse) than TCP).

The hard part about multiple sockets is how are you going to tell the clients which port to connect to? This is doubly hard when NAT is involved, where the port the server thinks it is using is not necessarily the same as the one the client thinks it is using. Real networks almost always involve NAT.

In addition, having multiple sockets doesn't buy you much, as you still have to handle random traffic arriving on the port that isn't from the "connected client". In fact, you may end up with even more spurious traffic as you're far more likely to collide with a known port if you have to generate new port numbers for each client.

The simplest solution with UDP actually turns out to have a single server port, and use the packet's IP address and port to lookup which client, if any, the packet should be associated with.

Sockets are an OS-level concept, and are not visible on the network.

For most OS-es, for TCP sockets, there is one accepting socket, and each time a new client connects, the OS creates a new socket for you; writing to and reading from that socket will communicate with the client in question.

For UDP, you typically only use a single socket, as there is no "virtual circuit" or "connection" like in TCP. Instead, you can tell whether an incoming packet is from a known client by looking at the source address of the packets you receive, and you respond to the right client by using the sendto() function, specifying the address you got out of recvfrom().