Теоретический вопрос. Алгоритм.

← →
Plastic Angel (2005-10-26 21:31) [0]

Доброго времени суток,уважаемые.

Собсно вопрос пока теоретический и конкретного кода нет.
Интересует ваше мнение по поводу такой вот штуки.

Исходные данные(оно же - необходимое):
Некая система с архитектурой клиент-сервер (к примеру будем считать что это какой то навороченый чат с выделенным сервером)
В любое время работы нужно обмениваться(клиент-сервер/клиент-клиент) инфой различного рода (текст,файл, потоковое аудио/видео, какая то служебная инфа и т.д и т.п).
При этом - одновременно.
По поводу самого протокола - пакеты в виде _заголовок_+_данные_

Вопрос собсно -как? то есть сам алгоритм...
В моем понимании это примерно так:
В заголовке каждого пакета есть инфа какие именно данные идут.
Есть какой-либо пул_пакетов куда складываются различные данные на отправку и соответственно выбираются и отправляются по очереди.
Так же и на принимающей стороне - пакеты складываются в пул
и раздаются необходимым модулям на обработку.
То есть смысл в том чтоб отправляющая/принимающая подсистема(sockets) не ожидали когда определённый модуль обработает пакет а просто отдавали ему его и продолжали рабоать.

Ну и вопрос собсно насколько правильно я мыслю и может кто нить предложит полее эффективный алгоритм...?

Надеюсь что более-менее внятно объяснил вопрос...=)

Заранее спасибо за участие! =)

← →
Digitman © (2005-10-27 09:17) [1]

> насколько правильно я мыслю

мыслишь ты правильно, осталось только оформить эту мысль законченном (не сумбурном) в виде

иными словами, следует "отделить мух от котлет" - реализовать отдельно транспортный и исполняющий (прикладной) алгоритмические уровни.

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

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

← →
Plastic Angel (2005-10-27 11:16) [2]

> иными словами, следует "отделить мух от котлет" - реализовать
> отдельно транспортный и исполняющий (прикладной) алгоритмические
> уровни.

Ну собственно так я и хотел сказать..)
Хочу как раз cделать всю систему в виде модулей:
Верхний уровень я считаю вообще не должен "знать" как там "внизу" происходит отправка данных - просто отправляет кусок данных дипетчеру - а тот уже взаимодействует с трнспортной подсистемой. Соответственно и транспортная подсистема не разбирая данные просто отправляет их диспетчеру или удалённой стороне.
"Помойму так!"(с) Винни Пух

Только вот чета сообразить не могу... Кто должен делить данные на пакеты - "исполняющий" или "диспетчерский" уровень?
То есть к примеру надо отправить файл и во время отправки обмениваться сообщениями...
Так вот отправитель должен делить файл на определённые куски и добавлятьв пул или диспетчер сам будет делить и заодно вставлять пакеты от другого модуля(текст)...

То есть собсно нужно сделать автомат преобразующий парралельные потоки данных в один последовательный...Но вот как это наиболее эффективно сделать..?

PS: кста...по поводу транспортного уровня... есть ли какая либо разница(по производительности) между чистым socket (то есть используя Win API), компанентами TClientSocket/TServerSocket и Indy.
Вопрос именно по производительности а не по удобству программировния...

← →
Digitman © (2005-10-27 12:34) [3]

> Кто должен делить данные на пакеты - "исполняющий" или "диспетчерский"
> уровень?

вполне логичным может выглядеть решение, при котором диспетчер оперирует "пакетами" как готовыми (как для транспортного уровня, так и для прикладного) "объектами".

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

т.о., ответственным за "деление на "пакеты" резонно назначить исполняющий уровень, ибо только он "знает" что и где взять/обработать.

> есть ли какая либо разница(по производительности) между
> чистым socket (то есть используя Win API), компанентами
> TClientSocket/TServerSocket и Indy.
> .. по производительности ..

Прямое использование WinsockAPI, разумеется, даст наивысшую производительность и наинизшее удобство.

Использование TClientSocket/TServerSocket даст максимальную гибкость/производительность транспортной подсистемы, ибо эти компоненты есть ничто иное как чистой воды транспорт, безо всяких сомнительных в необходимости "наворотов" над ней ..
По сути эти компоненты инкапсулируют функциональность Winsock-подсистемы, делая обращения к ней из приложения насколько это возможно удобными ...
"Надстройка" здесь минимальна, поэтому она вносит мизерную лепту в конечную производительность трансп.подсистемы ...
Следует отметить и факт "заточки" этих компонентов именно под Windows и , соответственно, под Winsock базовой версии (v1.1).

Indy-компоненты сочетают в себе платформонезависимый транспортный уровень и прикладные надстройки над ним (FTP, SMTP, HTTP и т.д. и т.п.) .. Поэтому если не требуется мультиплатформенность будущего приложения и требуется гибкость его трансп.уровня (основанная на особенностях и технол.возможностях конкретной ОС, а именно - Windows), выбор Indy в кач-ве "чистого" транспорта вряд ли оправдан.

← →
Plastic Angel (2005-10-27 13:32) [4]

Ок.Приятно что я мыслю в правильном направлении.Осталось дело за малым -написать =)
Огромное спасибо за такие подробные ответы.
Радует что есть хорошие люди на этом форуме =)

← →
Digitman © (2005-10-27 13:42) [5]

> Осталось дело за малым -написать

"Эт точно !" (С) Ф.Сухов

> Огромное спасибо за такие подробные ответы.
> Радует что есть хорошие люди на этом форуме

приятно отвечать на вполне грамотно поставленные вопросы.

Digitman © (27.10.05 09:17) [1]

Извини, что вставляю пять копеек. Тот что между транспортным и прикладным - называется сеансовым. ;>

Теоретический вопрос. Алгоритм. Найти похожие ветки