2011-03-31 2 views
4

J'ai essayé d'utiliser IIS 7 (inclus dans Windows 7) pour tester une bibliothèque FastCGI que je suis en train de développer.FastCGI avec protocole = Tcp sur IIS 7

Selon la spécification FastCGI d'origine, lorsqu'une application est appelée, sa poignée stdin est remplacée par une socket. Par défaut, IIS utilise un tube nommé à la place, mais il est possible de le configurer pour utiliser TCP, c'est-à-dire un socket.

Lorsque j'essaie d'utiliser cette socket dans mon application de test, j'obtiens une erreur WSAENOTSOCK.

Lorsque j'essaie d'utiliser un canal nommé à la place (après avoir reconfiguré IIS), je rencontre des problèmes similaires. Par exemple, je reçois un ERROR_INVALID_HANDLE lorsque j'essaie d'utiliser PeekNamedPipe. ReadFile et WriteFile fonctionnent cependant correctement.

Je suppose que le problème est que ce handle est hérité du processus parent et le processus actuel ne connaît pas vraiment son type exact. Il semble supposer que le handle représente un fichier simple.

Est-ce que quelqu'un a rencontré des problèmes similaires et connaît une solution/solution de contournement? Puis-je en quelque sorte mettre à jour le statut in-process de mon handle de sorte que la fonction de l'API WIN32 l'accepte comme socket/tube nommé?

Répondre

3

Au cas où quelqu'un d'autre tomberait sur ce sujet: DuplicateHandle fait l'affaire.

En fait, la fonction OS_LibInit du libfcgi implementation montre comment démarrer une application FastCGI qui a obtenu son socket via stdin.

+0

Assurez-vous de marquer ceci comme la bonne réponse. – Kev