> У сервера нет никакой инициативы.

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

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

> Медвежонок Пятачок ©   (08.09.11 11:08) [17]

Иначе это не сервер, а спамер.

> RGV ©   (08.09.11 11:19) [20]

Надо сменить идеологию, надо что бы клиент стал сервером, а сервер клиентом и всего делов. И никаких таймеров

> Anatoly Podgoretsky ©   (08.09.11 11:31) [22]


Издеваетесь?
А можно по подробней про идеологию?

Вот бы на исходничек взглянуть "правильного" клиента, и "правильного" сервера, разумеется на Indy.

> Anatoly Podgoretsky ©   (08.09.11 11:31) [22]

Я понимаю, что ломать парадигму задача не тривиальная,  все ж таки попробуйте мне объяснить эту вашу идеологию.

> RGV  (08.09.2011 11:41:23)  [23]

Считай сам как хочешь, желание что либо отвечать совсем пропало.

> Anatoly Podgoretsky ©   (08.09.11 12:03) [25]


Я прошу прощения, если чем вас обидел.

> Для начала можно попробовать свыкнуться с мыслью, что сервер
> - это обслуживатель запросов клиента.
>
> Нет клиентского запроса - сервер курит.

Не всегда так. В ряде случаев долбать сервер постоянным опросом со стороны клиентов - накладно слишком, поэтому сервер может уведомлять клиентов сам по собственной инициативе о событиях. Стандартная практика.
Например, видел такое в интерфейсе Asterisk, в Mailru тоже вроде.


> Клиент что-то отправил серверу и ждет ответ на посылку.
> Сервер в это самое время решил что -то наотправлять клиентам.
>
>
> И клиент вместо ответа на одну конкретную команду получает
> от сервера ответ, никак не связанный с отправленным запросом.
>

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

Т.е в такой асинхронной схеме существует 3 типа посылок:

1. Команды клиента. Требуют ответа сервера.
2. Ответы сервера. Высылаются в ответ на команды клиента.
3. События сервера. Высылаются клиенту. Ответ на них не требуется.

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

> DVM ©   (08.09.11 23:25) [29]

 Спасибо.
 TServerSocket, TClientSocket для этих целей может подойти?
 synapse?

> RGV ©   (09.09.11 04:23) [30]

ICS лучше всего

Не всегда так. В ряде случаев долбать сервер постоянным опросом со стороны клиентов - накладно слишком,

Чем накладно-то?
У него постоянный коннект клиента и сервер держит его сессию все время пока клиент не выйдет.
Вся накладность - в количестве байтов гоняемых по сети.

> Медвежонок Пятачок ©   (09.09.11 10:47) [32]


> Чем накладно-то?


> Вся накладность - в количестве байтов гоняемых по сети.

Сам же ответил. Данные будут гоняться, даже если нет для клиента никаких сообщений. Если клиентов мало - это ерунда конечно, но представь если таким образом сервер будет обслуживать 1000 клиентов. Значительная часть процессорного времени будет уходить только на ответы клиентам что данных нет (причем в большинстве случаев бестолковые). Туда же будет уходить и трафик (иногда критично, например, в случае GPRS). Зачем это все? Не проще ли переломить себя и наделить небольшой инициативой сервер?

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

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

но представь если таким образом сервер будет обслуживать 1000 клиентов.

Прикинь, не могу.
В этом кокретном случае.
Я даже не могу представить, что на предприятии автора когда-то внедрят эту подпорку (если он таки сделает первую альфу)
Так что ни о каких тысячах речь не идет.
Речь идет об обмене с его младшей сестрой.
Пять минут после написания проги.
Затем сестра снова уйдет во вконтакт со словами "не приставай ко мне со своей ерундой".

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

> Медвежонок Пятачок ©   (09.09.11 11:18) [35]


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

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

В другой ситуации возможно надо придерживаться схемы запрос-ответ.

> DVM  (09.09.2011 10:56:33)  [33]

Да и постоянное подключение тоже в некоторых случаях накладно, когда
почасовое подключение.

> DVM  (09.09.2011 11:01:34)  [34]

Так делается это методом замены ролей, клиент становится сервером и
наоборот, но автор это не воспринимает.

> Anatoly Podgoretsky ©   (09.09.11 11:58) [38]


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

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