web services - services - ¿Programación de socket vs. servicio web?
web service wsdl ejemplo (1)
Quiero crear un servicio de mensajería móvil, pero no sé cuál es mejor usar una programación de socket o un servicio web.
¿Cuáles son las preocupaciones que debo tener en cuenta al crear dicho servicio? como el costo de conexión ... etc.
Si necesita más información, solo dígame antes de votar la pregunta o cerrarla.
Por lo general, los servicios web son "más fáciles" de hacer, gracias al enorme interés que despiertan en ellos y al apoyo que reciben en las herramientas de desarrollo y en las bibliotecas y los marcos.
Sin embargo, especialmente si su carga es pequeña (piense en mensajes del tamaño de un SMS o tweet típico), la sobrecarga que crea con servicios web es prohibitiva: los bytes enviados a través de una red inalámbrica como GPRS o UMTS siguen siendo muy caros, en comparación con los bytes transferidos cable o ADSL. Y los servicios web tienen varias capas de información invisible que el cliente final también tendrá que pagar.
Entonces, si su caso de uso se basa en mensajes cortos, al menos le aconsejo que haga algunos cálculos de simulación de ancho de banda, y base su decisión en el ahorro de ancho de banda frente a la mayor complejidad de su aplicación.
Mientras mira los sockets, también eche un vistazo a UDP: si puede vivir con el hecho de que básicamente le arrojas un paquete a alguien, y sin diseñar ningún mecanismo de acceso en tu protocolo nunca estarás seguro de que el mensaje llegó, es muy eficiente porque no hay tráfico para crear y mantener una conexión, e incluso mensajes bastante largos pueden transportarse dentro de 1 paquete UDP.
EDITAR basado en un comentario:
- socket de flujo: no estoy seguro de cómo definir flujos, pero las secuencias y los mensajes son dos conceptos muy distintos para mí, un flujo es una secuencia típicamente más larga de datos que se envían, mientras que un mensaje es una entidad que se envía y opcionalmente confirmada o respondida por el receptor.
- simulación de ancho de banda: la forma más fácil de entender de lo que estoy hablando es obtener Wireshark y sumar todo lo que se transporta a través de la red para hacer una simple solicitud de una cadena muy corta: verá varias capas de información administrativa (es decir, invisible, solo para hacer que las distintas capas de protocolo funcionen) que el usuario final paga por el tráfico. Luego, escriba un pequeño servicio simulado usando UDP para transportar el mismo mensaje, o use una herramienta como netcat , buen tutorial here y sume los bytes que se transportan. Verá diferencias bastante grandes en la cantidad de bytes que se intercambian.
EDIT2, algo que olvidé mencionar: las redes móviles solían ser redes abiertas y transparentes con dispositivos identificados por direcciones IP públicas. Existe una rápida evolución hacia las redes móviles NATed, que tiene un impacto en cómo los dispositivos dentro y fuera de este "jardín amurallado" pueden comunicarse ( recorrido NAT ). Deberá tener esto en cuenta al diseñar su canal de comunicación.
En cuanto al uso de streams para una aplicación de chat: ofrece algunas ventajas conceptuales, pero también puedes aplicar capas a una aplicación de chat sobre UDP, mira here o here