Avec la fonction getsockopt(...) on peut obtenir la taille maxi du buffer qui peut être reçu ou émis.
Il semble qu'avec un setsockopt(...) on puisse modifier cette valeur et par exemple l'augmenter. Mais savez-vous jusqu'à combien on peut l'augmenter ? Et y a-t-il des pertes au niveau des perfs réseau ?
Merci de tous vos commentaires et remarques !

Pour la taille du buffer, je pense que ça doit être 65535 au maximum
Plus la taille du buffer est grande, plus il y aura d'informations qui vont circuler sur le réseau. Après pour les perfs, ça doit aussi dépendre du nombre de buffer envoyés par seconde

En fait mon but est de saturer complètement le réseau pour faire une sorte de streaming...

et bien tu fais une boucle infinie de write(socket,buffer,65535..)pour le serveur et le client fait un read de la même chose (avec des socket non bloquantes bien sûr !!)

Mais là je ne risque pas de perdre des données ?

Je pense que ça va saturer et que par conséquent des paquets seront perdus
ça dépendra d'abord du type de socket que tu utilises:TCP, UDP ou autre
et après, plutôt que de faire une boucle infinie sans aucun contrôle, tu peux règler un delai d'attente entre l'émission de 2 buffers
while(1){
    delai(100ms);
    write(socket,buffer,65535...);
}

Je suis parti pour faire du TCP.
Il ne devrait donc pas y avoir de pertes de données mais je me demande si je ne risque pas d'avoir des inversions du style :
send1...
send2...
 
reçu (send2)
reçu (send1) --> Aïe !
 
ou alors après chaque envoi, j'attends confirmation de la réception...

En TCP, ça devrait être bon puisque tu crées une socket TCP et c'est la couche TCP qui gère le fait que les paquets sont reçus dans le bon ordre
Je pense pas que ce soit une solution d'attendre confirmation après la réception de chaque paquet pq ça va encombrer encore plus la connexion TCP entre les 2 stations

TCP fait ca. Il s'engage à ce que les données arrivent dans l'ordre.

Alors si le TCP s'y engage...    
 
En tout cas merci beaucoup !