Salut

Je dois faire un client et un serveur avec une fonctionnalité assez simple :
le client doit demander au serveur de lui envoyer un fichier (d'une taille max d'environ 65ko, soit en un seul paquet normalement) en mode non connecté (UDP donc).
Le serveur, lui, ne soit pas bloquer pendant l'envoi du paquet, donc utiliser des threads.

Alors autant en mode connecté (TCP) c'est facile, il suffit de faire une socket d'écoute (listen) et de boucler sur accept, autant en mode non connecté j'arrive pas à me faire un schéma dans ma tête.

J'ai qu'une seule socket, donc comment je la partage entre les différentes demandes des clients ?

bah pareil, chaque client est dans son propre thread.

Le main va recevoir la requete des clients. Une fois que tu as parser la requete, tu passe le traitement de la requete a un thread.

En fait c'est recvfrom qui "joue le rôle de" accept ?
C'est une fonction bloquante je suppose ?

J'ai l'adresse du client, je lance un nouveau thread avec en argument son adresse et sa demande, je lis le fichier et je le lui envoie avec sendto.
Mais dans chaque thread, sendto va utiliser toujours la même socket, contrairement au mode connecté où accept retourne une nouvelle socket. Est-ce que les envoies seront bien simultanés ? C'est à dire, est-ce que depuis une même socket je peux envoyer simultanément différents paquets vers différents destinations ? Ou est-ce que, malgré le thread, les envois seront effectués séquentiellement ? Comment se comporte donc sendto ?

a la fin tout ca ca fait des write(2). man 2 write dit:

======================================================================
BUGS
According to POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with Regular File Operations"):

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2008 when they operate on regular files or symbolic links: ...

Among the APIs subsequently listed are write() and writev(2). And among the effects that should be atomic across threads (and processes) are updates of the file offset. However, on Linux before version 3.14, this was not the case: if two processes that share an open file description (see open(2)) per‐
form a write() (or writev(2)) at the same time, then the I/O operations were not atomic with respect updating the file offset, with the result that the blocks of data output by the two processes might (incorrectly) overlap. This problem was fixed in Linux 3.14.
======================================================================

donc pas de race condition.

sendto fait un appel à write, c'est bien ça ?

pas de race condition, ça veut bien dire que ça se fait pas en même temps ?

donc, le multi-thread est totalement inutile dans le cas présent ?

Pas de race condition veut dire que ton sendto (qui est équivalent à send() et write() d'après la doc), ne risque pas d'écraser/écrire en même temps dans le socket, si ce même socket est utilisé dans un autre thread.
Donc tu peux bien faire sendto() sur le même socket, il y a pas de risque

Ton architecture multi-threadé n'est pas inutile, elle permet de s'occuper indépendamment de chaque client. Sauf qu'au lieu que chaque thread possède sa propre "connexion" avec un client, il faut plutôt s'imaginer qu'un thread sera identifié à un client (adresse ip par exemple).

J’avais fait la même l’an dernier mais avec des fork au lieu des threads. Ça doit être le même principe.