I've got a few questions how to implement my Unity 3D game server. First of all some information of my game:

•It's a ARPG diablo style game.
•Must support multiple clients.
•Must support multiple games with 1 to 5 players.
•Game chat.

I have basic C++ UDP socket server (using one port) that receives a message and response to the client. Now I need to implement the multiple clients. My idea was when the server receives the messege from the client, create new thread (leaving the socket free to listen) and process the message (player position, events, etc..) then broadcast the response to the other clients in the same game, finaly close the thread.

1.Do I need to use threads when I'm using UDP socket to process the client message?
2.It's good my logic for the server?
3.The chat must be in separeted socket and port number?
4.The client will need to use threads to process the received message?
5.Any other suggestions how to implement the server?

1. No, using threads will probably make your life more difficult
2. Unclear what is being referred to as "good" here.
3. It doesn't have to be separate. It might make sense to separate it if you want a lightweight UDP game protocol (no retries, acknowledgements, de-duplication, etc), in which case having a separate TCP port for chat would avoid polluting the simple protocol.
4. Again, no need for threads here either.
5. Start simple. Avoid threads unless you have lots of experience with them.

Threads are expensive to create, you generally don't want a thread per message, or even a thread per client. Just ensure the calls you are using to poll messages aren't blocking or have a very shirt timeout.

If the number of game objects to be simulated can be high, the bandwidth required to sync all of them can be a challenge. Consider a "lock step" simulation approach, as outlined in the "1,500 Archers" article linked in the Forum FAQ.