>>7468
Я тоже думал для мультиплеерного чата использовать жаббер. Поделись потом кодом.
На все твои вопросы ответит стандарт xmpp.

>>7469
Нашёл
http://yapro.ru/web-master/xml/pishem-jabber-klient.html
Интересно, а как авторизоваться без шифрования?
А то сейчас не охото заморачиватся с ним.

>>7470
Просто найди библиотеку для твоего языка. Зачем это руками делать?

>>7474
Gambas ?

>>7475
Не пользуйся бейсиком. От ублюдочной пародии на неменее ублюдочный недодиалект ублюдков-дегенератов с комплексом неполноценности нельзя ожидать чего-то хорошего.

>>7476
Окай... буду читать книгу по c++ теперь...

>>7477
Для "продакшона" бери сразу C# - "похапе в мире С", под прыщи мигелюшка наковырял даже среду почти нормальную, правда, я ее не видел сам, но поцоны говорят, что хорошо зделали. C++ особо не полезен человеку, если он не знает обычного С.

>>7479
Планируется выпустить под открытой лицензией. Если конечно руки дойдут написать.

>>7479
>похапе в виндомире С
Поправил. Не стоит забывать о потере кроссплатформенности. Под виндовс наверное только на C# и удобно писать, на других языках очень плохо получается, если идти по пути наименьших самописных костылей. А если человек знает С, то проще писать на С.
>>7480
А давай кооперироваться. У меня есть движок, опыт и планы.

>>7481
Видишь ли, я хочу написать хардкорный космосимулятор.
То есть никаких защитных полей, ёба-фигни и всего прочего.
Основная часто геймплея это ковыряние астероидов и полёты по инерциальным траекториям.
Не факт что вообще начну писать, ещё много чего надо учесть на этапе проектирования. От сопротивления материалов до гравитационных эффектов.

>>7483
Зачем это учитывать тебе, когда с этим прекрасно справляется физический движок?

>>7484
К примеру, какие движки могу обеспечить нормальный расчёт десятка планет и 85000 прочих объектов на разных орбитах?

>>7486
Ты правда думаешь, что обсчитывать все сразу - правильное решение?
Если ты думаешь, что ты вот так возьмешь и напишешь свой собственный движок, который будет быстрее, чем существующие - брось эту затею. Ты потратишь огромное количество времени, но единственное, чего добъешься - интерфейса, которым тебе будет удобно пользоваться (и то не всегда), потому что делал под себя. В остальном обойти существующие библиотеки, разрабатывающиеся не один год, имеющие какое-никакое коммунити начав разработку с нуля и не имея опыта построения физического движка (у тебя же его нет, я правилно понял?) практически невозможно. И потом, ты же не только физику делать будешь, глупо тратить на нее все время.
А кооперироваться я хотел в основном в плане мультиплеера. Все равно, как на игры не смотреть, а все их схожие части устроены по одному-двум наиболее оптимальным принципам. Так как эту область я еще не рассматривал всерьез, то облегчение поиска оптимального решения было бы очень кстати. Мой опыт напоминает мне, что даже решая разные, но схожие задачи, при постояннм обмене мнениями, решения получаются быстрее и лучше.

>>7487
хм.. ну тогда подкинь мне на c++ примеры как принять много соединений и обрабатывать их.

>>7488
Демон с сокетами же. Вообще, мне кажется, лучше поискать готовое решение.

>>7492
Поискал реализации разные, что не нашёл нормальных.

>>7492

>демон с сокетами

Сообщение ниочем.

Гуглить надо в сторону select\epoll для прыщей либо 4 года не кодил ни строчки под богомерзкие форточки поэтмоу невкурсе

Достаточно годная вводная статья. В конце есть вполне понимабельный пример для осознания основных концепций неблокирующих сокетов.

http://www.rsdn.ru/article/unix/sockets.xml

>использовать джаббер для чата
Ну это пиздец, честное слово. Не умейте байтики по сокету посылать?

>>7497 Байтики пересылать просто, но возникает ряд проблем, связанных с NAT'ом, закрытыми портами, и прочей фигней, делающей соединение по UDP через интернет затруднительным, например. И при большом числе соединений сервер надо тоже грамотно написать. А тут готовое решение в виде jabber-сервера всей маршрутизацией занимается.
мимо проходил, идея понравилась-кун

>>7496
Я тут подумал, если на запуск нового процесса требуются большие системные ресурсы. Как бы запустить их заранее?
(обработка запросов форками)

>>7498
У серверов "мгновенных" сообщений часто неприемлемые для игр задержки.

>>7498
>по UDP
TCP.

>И при большом числе соединений сервер надо тоже грамотно написать.
Потоки.

>готовое решение в виде jabber-сервера
В Visual Basic вообще есть готовый компонент. Пиши на VB.

>>7494
Под готовым решением я подразумевал не superlibraryyoupblemsolver-99.68.so, скорее всего конкретно такой штуки никто не писал, а посмотреть, как это сделано в популярных/какие найдутся опенсорсных мультиплеерных играх и на основе этого сделать выводы. Если найти под MIT, можно еще и невозбранно украсть всю подсистему, не придется выдумывать протокол.
>>7496
Не узнал оттуда ничего нового, на самом деле. На практике скорее всего придется делать не какой-то из тех вариантов, а что-то среднее. Несколько тредов-пуллов, в каждый из которых по очереди отправляются выбранные сокеты.
Проблема тут скорее не как реализовать, потому что это почти очевидно, а что реализовывать. Нужна ли клиент-серверная архитектура, или это будет хотсит/ipx/диалап-мультиплеер, каким образом передавать данные, как часто, какие именно данные передавать, как обрабатывать несколько клиентов, как их синхронизировать. Простой клиент-сервер можно написать за полчаса-час, но без интеграции он не нужен.
>>7497
Но зачем придумывать свой протокол, когда есть готовый с кучей плюшек, которые можно использовать под внутриигровые нужды?
Никто же не предлагает интегрировать в игру ежа вместе с его эрлангом.
>>7499
Не делай форками, у операционных систем есть лимит на количество форков, он довольно невелик. Сделай пулл с несколькими тредами.

>>7502
Тогда не получиться не кроссплатформенно.

>>7502 ну TCP для сообщений пожалуй пойдет, да. Хотя будет лочить канал, что не есть гуд.

По поводу потоков: вот есть у тебя например 10к клиентов, ты под каждого будешь поток открывать? В этом случае надо клиентов каким-то образом группировать, и уже под группу делать поток.

Про VB спасибо, но нет. Я к нему не прикасаюсь с 1 курса института. Сейчас я цэпэпэшник до мозга костей. И что там за компонент? Вряд-ли в дотнете есть компонент "крутой универсальный сервер для обмена произвольными сообщениями через интернет для любого количества клиентов"

>>7514
хм.. а есть в c++ способ узнать событием на какой из потоков пришли данные? Что бы не перебирать все каждый квант времени?

>>7515 не понял вопроса... Есть, например, набор одинаковых потоков, запущенных для каждого клиента. В каждом потоке выполняется какая-то главная функция, назовем ее Run, например. В функции Run есть бесконечный цикл, который повторяется до разрыва соединения или отсоединения клиента. Внутри бесконечного цикла происходит прием данных из сокета функцией recvfrom. То есть принятие данных происходит в каждом потоке отдельно, и соответственно обработать их можно отдельно. Например, при получении нового пакета, вызвать callback-функцию у объекта клиента, сопоставленного с этим потоком

>>7517
А теперь я ничего не понял. Видимо надо уточнить.
Что такое поток в данном контексте и как он обрабатывается?

>>7518 поток - это поток операционной системы, thread. А что еще можно понимать под потоком?:3

>>7519
А какая тогда разница между потоком и процессом? Или несколько потоков в одном адресном пространстве просто? Как в сях создаются потоки как с ними работать?

>>7515
я предпочитаю не опрашивать потоки о результатах, а учу поток уведомлять о том, что работа выполнена (callback-функция словами >>7517-стива)
Процессами считаются отдельные приложения, потоками - самостоятельно друг от друга выполняющиеся алгоритмы (за исключением контрольных секций и синхронизаций), но в рамках одного процесса (адресного пространства, как ты выразился).

>>7523
после написания этого поста даже возникла мысль, какой же твой "родной" язык, если ты таких мелочей не разбираешь.

>>7520
Для самих сей и плюсов (до нового стандарта) потоков нет - есть платформозависимые библиотеки, которые эти потоки организуют. На posix - pthread, на виндах - winapi и порт pthread. В плюсах boost.thread, а так же новый стандарт языка умеют треды.

>>7524
Visual Basic

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

>>7529>>7524

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

>>7559
Спорное утверждение, если somelang === php.

>>7559
Да чего уж там, "программист", давай сразу под "компьютерщика" обобщать. Если разбираешься в компьютерах, то и программу напишешь, и видюху распаяешь, да что там, и микроскеху прошьешь.

>>7559
тоесть ты либо программист, либо ... [spoiler]кодер на языке somelang[/spoiler]

>>7560

phpшники не программисты. Навидался я на них.


>>7561

А вот и нет. Как раз таки эксплуатировать ПО можно вполне обойтись знаниями общих принципов без вникания в тонкости именно написания.


>Да чего уж там, "программист", давай сразу под "компьютерщика" обобщать.

Ойтишник еще скажи. Хотя мне употребителям этого термина хочется плеснуть чай в лицо


По тебе основной дискуссии - ОП, почитай уже про libevent и не пар сознание.

>>7565
> phpшники не программисты. Навидался я на них.
Чиочую.
Похапешник - это дизайнер, проектировщик баз данных, проектировщик интерфейсов - кто угодно, но не программист.

Можно я тут потестирую кое-что? С сажей тред не должен подняться. Спасибо

>>7520
10 лет посту!

>>26485
А джаббер еще жив!

>>26485
Я-то думаю чего доска такая живая вдруг. Не написал ОП свой космосимулятор...

>>26500
Просто за него хардкорный космосимулятор написали в Мексике.

>>26500
Возможно, он осилил и перешел на высший уровень бытия. И ему уже не до нас, в солнечной Калифорнии.