Частота посыла пакета (TServerSocket и пт)

← →
antonn (work) (2008-05-19 13:13) [0]

начал юзать сеть, пишу игрушку, чаты и логические (медленные) игры уже пройдены. Игрушка более менее требовательная к сетевой составляющей. Использую копмоненты TServerSocket и TClientSocket. Игра представляет собой массовую атаку всяких вражин на игроков, кол-во игроков ну 8, а вот вражин допустим 500 (короче много). Все они на сервере, сервер клинтам отправляет 10 раз в секунду состояние поля всем игрокам. Размер структуры на каждого монстра 13 байт. Итак сам вопрос - это реально 10 раз в секунду каждому игроку отправлять пакет по ТСР размером 640 байт? По сути меня смущает не объем отправляемых данных, а частота отправления. Реально ли этого? Проверить пока не могу:)

← →
Сергей М. © (2008-05-19 13:31) [1]

Простые примерные расчеты:

Минимально необходимая пропускная способность сети 640 * 10 * 8 ~ 56 кбод

Это без учета накладных расходов транспортного+межсетевого+сетевого уровней (по модели OSI). С учетом оного и прочих общесистемных ~ 100 кбод

Если это условие обеспечивается, то остальное не столь существенно.

А зачем собссно нужна периодическая доставка пакетов всем клиентам ? Достаточно отправлять изменения игровой ситуации, а не все ситуацию целиком.

← →
antonn (work) (2008-05-19 13:51) [2]

> Сергей М. © (19.05.08 13:31) [1]

ну ты в кримсонленд и его клоны играл? :) там обычно все шевелится и бегает в больших кол-вах (хоть и медленно, короче мясо обычное), поэтому я предполагаю наихудший вариант. Даже с учетом только изменений и отправки только видимых вражин. Сеть - Т1 или адсл от 128кбс. Меня просто смущает частота отсыла...

← →
Сергей М. © (2008-05-19 13:55) [3]

> ты в кримсонленд и его клоны играл?

Я похож на великовозрастного детинушку, которого кроме компьютерных цацек больше ничего не интересует ?)

> Меня просто смущает частота отсыла

А вот чтобы не смущала, не следует делать это периодически, а следует отсылать только дельту, т.е. инф-цию об произошедших изменениях на сцене.

← →
antonn (work) (2008-05-19 15:21) [4]

> Я похож на великовозрастного детинушку, которого кроме компьютерных
> цацек больше ничего не интересует ?)

ой ну такой сурьезный, куда бы деться)))

ладно, попробую переделать архитектуру (и самому ясно, что как то кривовато), попробую дома на практике :)

← →
DVM © (2008-05-19 15:25) [5]

> Итак сам вопрос - это реально 10 раз в секунду каждому игроку
> отправлять пакет по ТСР размером 640 байт?

Конечно реально. Это небольшой объем.

← →
Сергей М. © (2008-05-19 16:37) [6]

> DVM © (19.05.08 15:25) [5]
>
>

> Это небольшой объем

Смотря для кого он "небольшой")

Даже при идеальных на стороне сервера условиях засада может поджидать совсем в других кустах - на стороне удаленного клиента, который работает, скажем, через GPRS-модем.

← →
DVM © (2008-05-19 17:30) [7]

> засада может поджидать совсем в других кустах - на стороне
> удаленного клиента, который работает, скажем, через GPRS-
> модем.

ну в требованиях к игре оговаривать надо минимальную пропускную способность канала.

← →
antonn (work) (2008-05-19 18:11) [8]

> Конечно реально. Это небольшой объем.

так вот меня и смущал не объем, а частота. Типа задержки чтобы не были большие. Объем кстати может возрасти до 1Кб. Ну и думаю сделать игру в пределах 100Мбит

← →
Сергей М. © (2008-05-19 21:04) [9]

> меня и смущал не объем, а частота

Она-то тут причем ?
Пропускная способность той или иной подсети в сети на самом ее "узком" участке - главное "узкое место".

> Объем кстати может возрасти до 1Кб

Что уж там мелочиться ?
Завтра ты захочешь гонять по сети видео и аудио - тут и 50 кб не ограничение)

> думаю сделать игру в пределах 100Мбит

Ну и нафих такая кому нужна в наше время, когда для многих и пол-мегабода есть счастье великое ?

← →
antonn © (2008-05-19 23:14) [10]

> Она-то тут причем ?

лаги будут :)

> Завтра ты захочешь гонять по сети видео и аудио - тут и
> 50 кб не ограничение)

да, я работаю над этим %)

> Ну и нафих такая кому нужна в наше время, когда для многих
> и пол-мегабода есть счастье великое ?

а это типа велосипед, не для народа, больше для себя :)

вот еще один вопрос родился - как заставить Socket.SendStream(); не убивать передаваемый стрим?

← →
Сергей М. © (2008-05-20 08:20) [11]

> как заставить Socket.SendStream(); не убивать передаваемый
> стрим?
>

Без переделки TCustomWinSocket никак.
А зачем ?

← →
antonn © (2008-05-20 08:56) [12]

ну будет у меня код отправки всем клиентам:
for i:=0 to FServerSocket.Socket.ActiveConnections-1 do begin FServerSocket.Socket.Connections[i].SendStream(ms); end;
и в каждой итеррации цикла придется создавать ms, копировать в нее другой поток (тот, который нужно передать) и отдавать сокету. Каждый раз создание объекта, копирование, убийство... имхо было бы лучше, если бы создался буфер один раз не только на вызов процедуры, а в течении жизни класса (в котором FServerSocket)

← →
Сергей М. © (2008-05-20 09:07) [13]

> было бы лучше, если бы создался буфер один раз не только
> на вызов процедуры, а в течении жизни класса

Ну возьми да создай его, в чем проблема ?
Ничто не мешает использовать SendBuf вместо SendStream.

← →
Sha © (2008-05-20 11:54) [14]

> antonn
Посмотри, как сделаны эмуляторы WOW, найдешь много интересного.

← →
antonn (work) (2008-05-20 13:48) [15]

> Ничто не мешает использовать SendBuf вместо SendStream.
>

уел, сдаюсь, не посмотрел внимательно, пойду убьюсь :)

> Sha © (20.05.08 11:54) [14]
>
> > antonn
> Посмотри, как сделаны эмуляторы WOW, найдешь много интересного.
>

есть пара ссылок, пожалуйста?

> пойду убьюсь

Рановато, не доуел еще)

Полагаю, что дальнейшее движение к цели обязательно покажет. что данные, отправляемые клиентам, все же будут различны, так что придется с каждым из них ассоциировать свю очередь отправки. И это означает, что SendStream при прочих равных условиях будет выглядеть все же удобней и предпочтительней)

← →
antonn (work) (2008-05-20 15:28) [17]

да мне с самого начала посыл стрима понравился, жаль он там внутри себя буфер не держит, а мой киляет :( ладно бы я подсовывал только что созданый, так нет, он не знает что мой стрим "постоянный"... вообещ ен понимаю логики... сделали бы уже опционально. расковыряю наверное исходник сокета, сделаю SendStream2() %)

> ладно бы я подсовывал только что созданый

А тебе и так придется все время новый стрим создавать (или перезаписывать его содержимое, что не исключает реаллокации памяти под буфер в составе стрима), если прикладной протокол будет предусматривать отправку изменений.

И ничего страшного, кстати, в частом конструировании стрима нет - основные "тормоза" приходятся на реаллокацию в сторону увеличения внутреннего буфера стрима, а не на его конструирование. И это тоже не великая проблема, если воспользоваться менеджером памяти, оптимизированным в части увеличения производительности операций реаллокации и/или сборки мусора, например, FastMM4.

> расковыряю наверное исходник сокета, сделаю SendStream2

Вот уж глупее затеи не придумать)

Если уж тебя одолели лавры Кулибина, сделай своего наследника стрима, перекрой в нем деструктор и возбуждай в перекрытом деструкторе исключение, а "снаружи" лови его и гаси - вот тебе и простейший обход нежелательного поведения SendStream, безо всякого коверкания исходников компонента)

> antonn (work) (20.05.08 15:28) [17]

Мне кажется, что было бы лучше вообще не использовать TServerSocket и TClientSocket, а сделать свои сервера и клиента. Для конкретной задачи это будет и более производительное и более удобное решение.
TServerSocket и TClientSocket хороши для относительно простых задач без экзотики.

> [0] antonn (work) (19.05.08 13:13)

реально, только не забудь алгоритм Нагеля для сокета отключить, а то задержки будут.

Частота посыла пакета (TServerSocket и пт) Найти похожие ветки