El protocolo elegido para el demonio de ejemplo es relativamente sencillo, al menos la implementación de una pequeña parte. Pero el factor determinante para que el código del demonio fuera simple ha sido el uso de inetd como herramienta.
Pero no todo son ventajas. En este caso el lenguaje utilizado para programar el servidor no permite disponer de mecanismos para evitar ataques de denegación de servicio.
Si un cliente malintencionado quisiera atacar un servidor empleando db-httpd, solo tendría que hacer conexiones y no realizar ninguna petición. El demonio quedaría entoces bloqueado esperando leer de la entrada estándar. Es cierto que la configuración del super-servidor nos permite minimizar el impacto de estos ataques, dista mucho de ser una solución óptima para un sistema en producción.
Una buena mejora para el demonio de ejemplo sería posible empleando un shell como BASH, que permite dar un parámetro extra a las llamadas read con el que especificar un tiempo máximo de espera (timeout), evitando así el bloqueo indefinido.
Por último hay que mencionar que, junto a los posibles problemas que se pueden dar debido a la posibilidad de emplear lenguajes poco habituales en la programación de servicios de red, inetd posee sus propias limitaciones, como es la posibilidad de llevar un registro de las peticiones (logs).