LINUX.ORG.RU

На чем сделать свой чат-сервер?


0

0

Дано: веб-игра, 1500 юзеров, 1500 открытых сокетов, каждый из них как минимум раз в 10 секунд шлет запрос (перемещение персонажа в игре) и ожидает получить ответ (перемещение соседних персонажей).

Идея реализовать это в виде чата с сообщениями, вроде:

user1237|updatelocation|2342434|4567234|98273648|weapon7used

И пачка похожих сообщений в ответ. Протокол текстовый или бинарный.

Вопрос: в чем сейчас модно слушать порты, порождать/не порождать кучу дочерних процессов, разруливать синхронизацию между ними. netcat+bash не предлагать.

anonymous

Ответ на: комментарий от Deleted

затем что есть готовые библиотеки и целые XMPP/Jabber-ервера (ака XML-роутеры :D ), которые можно заюзать под проект, не изобретая велосипед

v12aml ★★
()
Ответ на: комментарий от v12aml

напомню:

>в чем сейчас модно слушать порты, порождать/не порождать кучу дочерних процессов, разруливать синхронизацию между ними

топикстартеру остается остальную функциональность прилипить в качестве, например, сервиса

а так же обрадовать юзверей "теперь вы можете общаться с людми из игры даже когда вы вне игры, использую QIP"

v12aml ★★
()
Ответ на: комментарий от Valeriy_Onuchin

> multicast udp

The architecture is quite simple:


- The server controls most of the game state information like objects position, score, even some basic physics. Changes in the internal state
of the game are computed at the server (a player moving to some
location, or a shot being fired, etc ... ) and is informed to the
clients mostly using asynchronous network messages (UDP packets).
LAN games uses multicast messages to save network traffic.
The server does not need to have a GUI.


- The clients need to connect (using TCP) and "register" at the
servers to receive updated game state data. The client does not use
local logic to update objects position or velocity. All the client do
is get updated game state from the server and render it. Also, every
user action (like the pressing of a move key) is not applied to local
object. This action is informed to the server using another
asynchronous network message.


Of course, implementations of this architecture uses a lot of tricky
optimizations methods, but this is the general idea.

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

>> multicast udp

Только в интернете и "не своих" локалках с шибко умными роутерами мультикаст работать не будет...

Deleted
()
Ответ на: комментарий от Deleted

>Только в интернете и "не своих" локалках с шибко умными роутерами мультикаст работать не будет...

а кому сейчас легко? :) 
Возможно, придется общаться через промежуточный сервер 
(который за рутером) по ssh tunnelю, типа (reverse proxy)
http://zarb.org/~gc/html/udp-in-ssh-tunneling.html

ssh == openSSL

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

ну и зачем делать все через одно место когда топикстартеру хватило бы IRC или ему подобного варианта

Sylvia ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.