2010-12-14 110 views
0

Revenez avec une question sur l'utilisation de C File stream dans la programmation des sockets. Je lisais à ce sujet et j'ai vu des critiques mitigées - certaines personnes disent que ce n'est pas fiable (abstraction fuyante?).Utilisation du flux de FICHIER C dans la programmation des sockets C

Quelqu'un at-il une vue sur l'utilisation du flux de fichier C dans la programmation des sockets?

+0

AFAIK, cela ne devrait fonctionner que sur certains compilateurs/systèmes d'exploitation , le cas échéant. – Simone

+0

Merci Simone! Je devrais vérifier si cela fonctionne sur mes plates-formes cibles ... – Poliquin

Répondre

4

Oui. Ne pas.

Les protocoles TCP et UDP ont trop de sémantique pour être facilement mappés à vos API de flux de fichiers habituelles. Cela ne veut pas dire que c'est impossible ou même difficile, mais il y aura probablement beaucoup de pièges et de cas limites qui vous donneront un comportement extrêmement imprévisible. Je ne peux pas penser non plus à la tête de toutes les applications où vous pourriez vouloir traiter une douille comme un fichier ordinaire. À la fin de la journée, une fois que vous avez traité avec la liaison et l'écoute et l'acceptation, rien de ce que vous pouvez faire avec les flux de fichiers C, et enveloppé le fichier de description résultant dans un type de flux de fichier, faire est utiliser fread() et fwrite(), peut-être fgetc(), donc vous pouvez aussi bien le laisser comme un descripteur de fichier ordinaire et nous recv(), et send() et vous épargner les tracas de l'emballage. Vous pouvez vous éviter les tracas liés à la mise en mémoire tampon, mais avoir le contrôle de la mise en mémoire tampon vous permet d'ajuster votre mémoire tampon aux exigences de l'application et de vous épargner une surcharge et une vitesse réseau.

+0

Merci AlastairG! J'ai beaucoup appris de votre discussion. – Poliquin

0

Cela dépend du type d'application que vous écrivez. Les flux FILE ne sont pas adaptés aux IO non bloquantes, asynchrones ou select/poll. Cela peut ne poser aucun problème pour un programme de ligne de commande qui exécute une tâche séquentielle de connexion à un serveur, de demande et d'obtention des résultats. Cela fonctionne également bien pour un processus serveur run-from-inetd-only. Mais si votre application fait n'importe quoi, vous avez des problèmes. Si vous voulez vraiment utiliser FILE flux avec des sockets dans une application événementielle, vous pouvez le faire en utilisant des threads, mais je doute que ce soit une bonne idée ...

+0

Merci R ..! Mon intention était d'opter pour des connexions asynchrones. Mais je pourrais l'adapter à un programme séquentiel pour l'instant. Mais je cherche quelque chose qui peut gérer au moins 80 connexions simultanées. Ces connexions enverront des données non-stop. – Poliquin