Как я писал свой чат Хабрахабр. Привет, Хабр О его архитектуре и о технических решениях принятых в ходе его разработки. Чат представляет собой клиент серверное приложение с элементами p. С поддеркжой Личных сообщений. Комнат. Передачи файлов. Голосового чата. Исходный код проекта Git. Hub. Итак, понеслась. Модель. Данные и их синхронизация. API. Запись и воспроизведение звука. Данные и их синхронизация. Но, почему то, напрочь забыл про то, что данные нужно синхронизировать. И так как серьезной нагрузки чат никогда не испытывал, то я понял это только после введения в чат передачи файлов. После этого сразу все вспомнилось и везде было вставлено куча локов. Сетевой Чат С Передачей Данных' title='Сетевой Чат С Передачей Данных' />Что разумеется не было лучшим решением. Если сказать точнее, то это было всего лишь чуть лучше, чем программа без синхронизации. Сейчас же на клиенте и на сервере используется единый механизм доступа к данным. Блокируется полностью модель. Должен сказать что для сервера это не самое удачное решение. Идея достаточно простая есть контекст, который приватным статическим полем содержит модель. В конструкторе он, вызывает Monitor. Enter. На саму модель, либо на отдельный объект синхронизации. Так же контекст реализует интерфейс IDisposable и в методе Dispose он эту эту модель освобождает, вызывая метод Monitor. Exit. Обобщенный класс используемый как для сервера, так и для клиента. Сетевой Чат С Передачей Данных' title='Сетевой Чат С Передачей Данных' />В примере модель содержится не в самом контексте а в классе его создающем. Код public abstract class Model. Contextlt TModel. IDisposable. Главное не забывать использовать конструкцию using. Для сервера это не является лучшим решением т. Она представляет собой класс содержащий статическую приватную модель саму себя, API а также клиентское соединение и пир для клиентской модели или сервер для серверной. Также клиентская модель, в отличии от серверной, содержит еще и события. Касательно настроек пользовательских данных и программных опций. Чат представляет собой клиентсерверное приложение с. Так как он уже предоставляет надежность передачи данных оставалось. Пишем чат для локальной сети, используя C Builder. Серверная часть. Разработка систем передачи данных, Программирование,. Сетевой Чат С Передачей Данных' title='Сетевой Чат С Передачей Данных' />Клиентсерверные мессенджеры для локальной сети предприятий. Клиентсерверный мессенджер для локальной сети. Корпоративный чат MyChat расширяет границы общения. MyChat клиентсерверный чат, идеально подходит для передачи. MyChat может работать внутри корпоративной сети, а также через Интернет. Обмен данными надежно защищен OpenSSL. Создание многопоточного консольный TCPчат в C, многопоточная обработка. Length передача данных. Сетевой Чат С Передачей Данных' title='Сетевой Чат С Передачей Данных' />На которые будет подписан пользовательский интерфейс. В общем эти классы выступают как основные для доступа к чему либо. В качестве примера приведу серверную модель она поменьше. Обратить внимание следует на метод Get создающий контекст. Код public class Server. Model. Она представляет собой класс хранящий в себе команды которые могут выполнятся на нашей стороне, и набор методов которые отправляют команды другой стороне Клиенту, если рассматриваем себя со стороны сервера. Для клиента это сервер или другой пир. В методах содержатся наиболее сложные команды, либо просто часто используемые. Работает вся эта система следующим образом как только клиент или сервер принимает пакет данных, он передает его на анализ в API. API просто считывает первые два байта сообщения и ищет у себя в словаре команду с нужным id, и возвращает ее. Или пустую команду, которая ничего не делает, если такого id нет. Дальше команде передается полученный пакет, и id приславшего его соединения и она выполняется. Также API имеет свой интерфейс, изначально его не было. Появился после того как я решил написать другую его реализацию, предполагалось что это будет защищенное API. Но потом мне это просто стало не интересно, и я не на долго забросил проект. Месяца на два. После возвращения к нему мне уже не хотелось все это делать, и я занялся реализацией P2. P. Клиент, кстати, умеет сам выбирать API, который использует сервер, и если такового не имеется он отсоединяется от сервера и говорит что не поддерживает серверный API. Это реализовано достаточно просто после того как сервер принял соединение он сразу же отправляет строку с названием своего API, а клиент собственно ожидает эту строку и устанавливает нужный интерфейс. Ну или не устанавливает, если такой не поддерживает. После этого действия уже идет апишный запрос регистрации пользователя на сервере. Метод сервера обрабатывающего принятые пакеты Код public class Data. Received. Event. Args Event. Args. Для сервера IServer. APICommand, для клиента IClient. APICommand, на данном этапе их можно было бы свести к 1 интерфейсу, но мне этого делать почему то не хочется. Также она содержит свой Id и данные необходимые для ее выполнения, описывающееся классом Message. Content. Впрочем команде могут быть и не нужны данные. И она сама ответственна за то, что бы десериализовать набор байт в экземпляр класса. Пример команды. В данному случае это команда добавления файла в комнату Код. IServer. APICommand. Но уже успел повозится с воспроизведением и записью звука. Первым вариантом были Win. Api функции wave. In wave. Out Это был самый простой вариант, поэтому начал с него. Но с ними не сложилось, т. При сборке под х. Дальше была попытка подключить Direct. Sound, но у него был найден свой баг с способом оповещения о завершении проигрывания куска данных. После гугления на эту тему выяснилось, что Mircosoft давно забросили Direct. Sound и работают с XAudio. К тому же его использование привело бы к необходимости компиляции 2ух версий х. Так как мне не хотелось самому писать обертку для XAudio. Open. AL. Для которого к тому же есть обертка Open. TK, еще и с открытым исходным кодом. Из Open. TK был аккуратно вырезан только сама аудио библиотека. Которая сейчас и работает в программе. Так как мне приходилось работать Open. GL ES 2, то и с Open. AL я подружился сразу. Особенное если учесть что по нему на официальном сайте Open. TK есть примеры. Для записи данных я использую достаточно простую схему, из примера. При включении записи, запускается таймер, период срабатывания которого настраивается на время, за которое буфер должен заполнится на половину. После чего данные из него считываются и отправляются командой Client. Play. Voice. Command всем кто может слушать нас. Код можно посмотреть в ветке TCPChatEngineAudioOpen. AL. Сеть. Изначально чат представлял собой одну главное комнату, где находились все пользователи. Из протоколов передачи данных использовался только TCP. Так как он уже предоставляет надежность передачи данных оставалось только разбить его непрерывный поток на сообщения. Это было сделано просто добавлением размера сообщения в его начало. То есть пакет представляет из себя следующее Первые 4 байта размер сообщения. Свечи Гексикон Способ Применения И Дозы Инструкция тут. Остальные данные это сериализованный Message. Content. Далее на одном форуме мне предложили ввести передачу файлов и голосовую связь. С файлами я справился почти сразу, правда в первой версии файлы передавались через сервер, что было вообще ужасно. После этого я задумался над тем, что хорошо было бы передавать их на прямую. Как вы знаете с проблемой NAT, это сделать не так то и просто. Я долго возился и пытался реализовать обход NAT используя TCP, тогда бы не пришлось парится по поводу ненадежности UDP. С ним так ничего и не получилось. После чего было решено использовать UDP и технологию UDP hole punching. А для начала надо было решить проблемы надежности. Как обычно бывает, я начал трудится над своим протоколом поверх UDP обеспечивающим мне надежную доставку сообщений. И он все таки у меня получился, но работал только локально. При его тестировании в реальных условиях он, видимо, настолько нагружал сеть, что у меня полностью зависал компьютер. После этого я начал искать уже реализованные библиотеки и наткнулся на сатью на Хабре, где аналогичная проблема была решена с помощью Lidgren. Network. Она и была выбрана. Обход NAT реализован на уровне API. Схема простая, нужно всего лишь, что бы пиры узнали реальные адреса, по которым их видит сервер. После этого один пир должен кинуть сообщение другому. Это сообщение возможно не дойдет, но создаст правило на роутере, что сообщения от того адреса, по которому оно было отправлено нужно доставлять именно этому компьютеру.