tcp read () immédiatement après accept ()

Si j’appelle send () immédiatement après le retour synchrone de connect (), est-il raisonnable de penser que l’appel à read () immédiatement après accept () du côté serveur renverra le premier segment de données? Par exemple, un client recevant le SYN-ACK attendra-t-il un peu avant de voir s’il y a une charge utile à inclure sur l’ACK lors de la prise de contact à trois?

Le premier message de mon protocole inclura un jeton d’authentification (<500 octets), et je pensais qu’il serait utile de lire () et de valider de manière synchrone immédiatement après accept (), et de fermer le socket s’il n’était pas valide. Sinon, il semble que je devrais avoir un état lié à l'attente d'un délai d'attente asynchrone. Je m'occuperai d'un ensemble limité de plates-formes clients communes, donc je ne me soucierai pas des possibilités théoriques dans toute l'implémentation de TCP.

Non.

Même si vous pouviez compter sur des clients bien comportés, les problèmes de réseau ne sont presque jamais sécuritaires.

De plus, lorsque vous utilisez des données non cryptées, toutes sortes de routeurs intermédiaires pensent qu’ils doivent se contenter des données.

Avec UDP, le problème est en fait plus simple, bien qu’il soit évident que vous devez implémenter vos propres algorithmes de contrôle de la fiabilité et de la congestion.

La réponse est non en général, mais Linux offre l’option de socket TCP_DEFER_ACCEPT, ce qui signifie que accept () ne revient pas tant que les données ne sont pas arrivées. Dans ce cas, read () immédiatement après accept () devrait renvoyer des données.