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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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


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


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


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


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

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

лаги будут :)


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

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


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

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

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

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


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

ну будет у меня код отправки всем клиентам:


и в каждой итеррации цикла придется создавать ms, копировать в нее другой поток (тот, который нужно передать) и отдавать сокету. Каждый раз создание объекта, копирование, убийство... имхо было бы лучше, если бы создался буфер один раз не только на вызов процедуры, а в течении жизни класса (в котором FServerSocket)

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


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

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

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

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


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

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

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


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

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

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

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


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

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


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


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

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

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

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

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

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