Creación colaborativa de dibujo pizarra aplicación

Question

tengo mi propio programa de dibujo en su lugar, con una variedad de "herramientas de dibujo", tales como pluma, goma de borrar, Rectángulo, Círculo, Select, texto etc.

Se hace con Python y wxPython . Cada herramienta mencionada anteriormente es una clase, que todos tienen métodos polimórficos, como left_down(), mouse_motion(), hit_test() etc. El programa administra una lista de todas las formas dibujadas: cuando un usuario ha dibujado una forma, se agrega a la lista. Esto se usa para administrar operaciones de deshacer/rehacer también.

Entonces, tengo una base de código decente en la que puedo enganchar el dibujo colaborativo. Cada forma se puede cambiar para conocer a su propietario, el usuario que la dibujó, y para permitir solo las operaciones de eliminar/mover/reescalar en formas pertenecientes a una persona.

Me pregunto cuál es la mejor manera de desarrollar esto. Una persona en la "sesión" tendrá que actuar como servidor, no tengo dinero para ofrecer servidores centrales gratuitos. De alguna manera, los usuarios necesitarán una forma de conectarse a los servidores, lo que significa algún tipo de buscador de "descubrir servidores" ... o algo así. ¿Cómo envío los cambios realizados a la aplicación? Dibujar en tiempo real y transmitir un mensaje sobre cada evento de movimiento del mouse sería costoso en términos de rendimiento y las cosas empeoran a más usuarios en un momento dado.

Todas las ideas son bienvenidas, no estoy muy seguro de por dónde empezar con el desarrollo de este (o incluso la forma de probarlo)

Answer 1

Hacer cualquier colaboración en tiempo real herramienta/juego se reduce a sincronizar de manera eficiente los cambios en una estructura de datos compartida mínima entre los clientes. El ancho de banda de la red es el cuello de botella. Envíe solo la información absolutamente necesaria para sincronizar los datos compartidos. Está en el camino correcto al almacenar formas en lugar de píxeles individuales. Sin embargo, las formas no deberían manejar los eventos del mouse. Como notó, la transmisión de eventos del mouse saturará rápidamente el ancho de banda de la red. En cambio, pase deltas de cómo las formas son alteradas por los eventos del mouse. Por ejemplo, en lugar de enviar mouse_motion() envíe la posición final [x, y] después de que se haya movido una forma.

Sugiero dividir su programa de dibujo en una parte del servidor y parte del cliente. El servidor conserva la versión autorizada de los datos compartidos. Un cliente nunca manipula la estructura de datos compartida directamente; solo envía mensajes de red al servidor. Esto puede parecer tonto cuando el cliente y el servidor están en el mismo proceso/PC, pero hay algunas buenas razones:

1. ruta de código compartido, tanto para un solo usuario y multi-usuario
2. La sobrecarga de la red entre un cliente y servidor en el mismo proceso es próximo a cero cuando se usan sockets locales

Además, la edición no tiene que estar limitada al propietario de esa forma. Dado que el servidor es la autoridad final, resuelve cualquier conflicto cuando dos personas toman la misma forma simultáneamente y envían los resultados a los clientes. (. Deshacer pone un poco difícil, sin embargo)

Aunque un servidor centralizado que es mejor para la detección de redes, los clientes pueden utilizar otros métodos para encontrar un servidor:

1. Enviar o escuchar a la red broadcast packets.
2. Conéctese directamente a través de una dirección IP. (La dirección IP del servidor deberá ser comunicada por otros medios: chat, teléfono celular, gritando por la habitación, paloma mensajera, ...)

Finalmente, observe cómo están diseñadas otras aplicaciones multiusuario. He aquí algunos ejemplos:

• Zoidcom Multi-jugador de la programación de juegos libary (C++). Gran parte de esta respuesta se basa en la información de la documentación de Zoidcom. Incluso hay programas de ejemplo que demuestran el descubrimiento del servidor a través de la transmisión de la red.
• Operational Transformation algoritmo detrás de Wave, Google Docs. (artículo discussion en Hacker News)
• Etherpad Editor de texto colaborativo de código abierto en tiempo real.
• Source Multiplayer Networking Explica cómo se diseña un FPS como HAlf-life. Se pone en trucos para reducir la lag/latencia.
• Google Wave (Al parecer, la documentación es bastante pobre stil ...)