client<->server
 

Всем привет
в общем пишу скромную мультипелереную космическую стрелялку с использованием TCP
работать то все работает...

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

еще бы знать как в играх организоввывать передачу пакетов... передавать 1 раз всю инфу 1им толстым пакетом? (сейчас я банки по 25-30 байт передаю... )

как часто надо обновлять клиент и сервер (передавать пакеты)
(вроде это называеться синхронихация)
сейчас я передаю каждые 10 мс

насколько тяжело писать аналогичный блицевскому СЕрвер На С++ , С, С#,Pascal,Delphi, qBasic (:-D )

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

я наверно предпочел бы C++ или аналогичные Сяподобные языки... как то они полезнее кажуца :)
что следует почитать про тцп на с++?
есть ли семплы рабочие написанные на цпп (аналогичные блицевским семплам про тцп... сервер, клиент, их общение)


как бы грамотно организовать вопрос.....

ну вот:
какой лучше выбрать инструмент для написания более менее нормального сервера для ОнлайнКосмическогоСимулятора
с расчетом от 50 человек онлайн (хотя играть будет не больше двуХ)

возможности в игре - летать стрелять...больше ничего нету :)

в блице использую PhysX ... пока не разобрался с некоторыми багами , но разберусь.

наверняка сервер для такой игры на блице написать не сложно (учитывая что мне осталось ток передавать покеты о факте выстрела... а так все уже готово)
но хочется что бы все было более грамотно... и хотелось бы знать как делаються северы НА САМОМ ДЕЛЕ

Ответ: client<->server
 

Если у тебя клиенты будут на блице, а сервер будет игровым, т.е. сервер будет вести именно 3д мир как он есть на клиентах, то... всеравно этот мир нужно тоже на блице делать, т.е. при этом от блица так и так не открутишься )) , хотя сам протокол можно обслуживать и какй-то либой, не обязательно блицевскими TCP функциями.
Другое дело если сервер только пересылает данные и не считает ни коллизий, ни каких-то расстояний, не ведет синхронизации по своему миру, тогда на чем угодно.

Ответ: client<->server
 

так :)
вот и новая информация....

ну сервер будет "неигровым"
тоесть в идеале я бы хотел достигнуть "досовского" окшка
запускаеш - конектишся и все :)

тоесть... сервер лиш передает информацию... пересылает ХП (ну тут же просто переменные)

на чем можно такое чудо написать? просто и быстро...
и где почитать инфу... семплы о сетевом кодинге на данном языке... насколько на ЦПП труднее писать севрер аналогичный блицевскому

Ответ: client<->server
 

Просто и быстро - это на высоких языках )) , ВБ, делфи или его сиобразный друг билдер. Там полно удобных компонент скажем indy, задача сведется практически к обработке событий.
Можно отказаться от TCP и взять либу RakNet, более быстрый протокол, удобство чем-то директплей напоминает, из блица юзается не хуже чем из других.
Это все если сервак будет у тебя дома )) , а если независимый, то наверно в сторону php надо смотреть, правда там свои особенности.
Есть совсем простое решение, которое я для себя выбрал - это готовые irc серверы, не лучшее, но полная халява ))

Ответ: client<->server
 

Люди как из блица прорваться через прокси?
При использовании стандартных функций подключения все виснет, не может подключиться так как все операции идут через прокси сервер и он блокирует передачу если не указаны логин/ пароль пользователя.
Пробовал дописать что-то типа autorization: proxy user passwd

Подскажите как правильно сформировать get запрос

Ответ: client<->server
 

Во! И я бы с удовольствием про это почитал. Тоже хз как с прокси быть. Причем прокси еще и разные бывают...

Ответ: client<->server
 

Ы? Надо просто в OpenTCPStream указывать ИП прокси, а хост и адресс указывать непосредственно в запросе

Но как прорваццо напрямую с помощью ТСР - мне неизвесто =\

Ответ: client<->server
 

Есть неплохой опыт в написании клиент серверных приложений если нужна подробная инфо то пиши в асю помагу icq: 444-530-841

Ответ: client<->server
 

Сейчас наткнулся на канувшую в пучине времени статью , на столько древнюю..., что высохли моря и океаны,и камни с тех пор превратились в пыль...гхм, так вот:) - "онлайн игра, это возможно?( конект 500+:rolleyes: ) ", и кое над чем поразмыслил , после слов Шуранова- все онлайн игры делаются на UDP, но ведь полностью полагаться на этот протокол нецелесообразно, ведь очень велика вероятность пропустить важные данные ,а с дерект плеем ободряющих результатов не достичь....
1 Так вот а если, создать некий "гибрид":rolleyes: , который будет, оцифровывать все не особо важные потоки на UDP, а там регистрацию, ввод паролей, ну и в общем важную хрень вместе с онлайн адаптером на ТСР :) ..... используя только блицевския команды- каких результатов ,предположительно, можно достичь ??
2 а если сюда ещё и "замесить" инакомыслящие библиотеки типа к-нет-либ:) ?
И наконец 3:) , разрабатывать клиентскую часть как и предполагалось бы в пункте 1 на блице(на блицевских стандартных функциях+ либы с МуСол) , а серверную часть писать на С++ тоже с МуСол:rolleyes:

или есть ещё какие то решения;) ?

Ответ: client<->server
 

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

Вобщем моё предложение по реализации Сервера, серв пишем на блитз, т.к. (сам в шоке был) программы написанные на блитсе работают как под вин так и под лин!

Реализации:
UDP протокл: формируем пакеты с заголовками заголовок пакета содержит в себе информацию о ID, длине и типе пакета, на клиентской тачке проверяем пришедшие пакеты по заголовкам и если пакет такойто с такойто длиной не соответствует описанию в заголовке, то отсылаем запрос на повторный пакет, иначе продолжаем выполнения операций с пакетами.

В данный момент как раз занимаюсь реализацией сие беспредельства. Есть так же примерная структурная модель работы сервер-клиента, если надо напишу

Ответ: client<->server
 

О да :) , модель была бы очень полезной;)
Т.е. ты предлагаешь полностью отвергнуть этот прожёрливый ТСР:rolleyes: , и всё писать на UDP с использованием мускуловской Дллки;)

Ответ: client<->server
 

Да ты прав, вот пример как будет реализованно обращение к мускулу

Короче сервер один раз обращается к бд собирая данные о пользователях, потом в процессе работы сервера он не обращается к базе!
Обращатся к мускулу он будет только в 4-х случаях!
1) Игрок зашол (собрали его данные, хп, координаты и т.д.)
2) Игрок вышел (сохраняем его данные, координаты и т.д.)
3) По требованию Администратора(посылаем спец комманду и серв сохр.)
4) При перезагрузке сервера.