Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TIdCmdTCPServer

Страницы: < 1 2 3 4 5 6 7 8 >
Zalm © (2009-08-31 13:14:00)
Здравствуйте, как у TIdCmdTCPServer можно всем клиентам разослать сообщение? Надо например каждому отослать команду. Это должно быть естественно в цикле, только я не знаю как и где. У TServerSocket было проще всё, ну или понятней.
1)Вот например у меня есть кнопка на сервере, как сделать чтоб ы при нажатии на кнопку каждому подключению что-то отправить, и что бы узнать его адрес там и тд?
2) Как узнать ip и handler подключения? и в каком евенте... если в OnConnect то я не опнля как...
3) Как вне событий отправить текст на подключение с известным адресом\обработчкиом?
Буду очень благодарен за помощь.

Сергей М. (2009-09-07 17:30:00) [81]

> если бы я писал через TServerSocket я бы не задавал таких
> тупых вопросов

Глубоко в этом сомневаюсь.
Были бы другие, но не менее тупые.

Сергей М. (2009-09-07 17:18:00) [82]

> я бы вобще не назвал то что мне нужно сервером

Обзови его хоть горшком - как он был сервером, так он им и останется.
Его задача - обслуживать(to serve) клиентов, если они не в состоянии сами себя обслужить.

> помощи не будет

Тебе уже 68 постов только и делают, что помогают, а ты все не внемлешь.

Медвежонок Пятачок (2009-09-07 17:17:00) [83]
фигасе заявки. "помощи не будет".

Zalm (2009-09-07 17:05:00) [84]
правильный сервер... я бы вобще не назвал то что мне нужно сервером.
Вобщем ладно, спасибо вам за участие в теме, понял что помощи не будет

Сергей М. (2009-09-07 15:47:00) [85]

> про то, что он почти никогда не нужен правильному серверу

С этим солидарен.

Медвежонок Пятачок (2009-09-07 15:45:00) [86]
Ну это само собой разумеется.
Но я-то про Среадс.ЛокЛист говорил конкретно.
Точнее про то, что он почти никогда не нужен правильному серверу.

Сергей М. (2009-09-07 15:34:00) [87]

> лочить ничего не надо

Ну как же не надо ?

> все происходит либю в OnExecute, либо в диспетчерах прикладных
> команд

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

Медвежонок Пятачок (2009-09-07 15:14:00) [88]
локлист нужен для операций по инициативе сервера.
допустим что клиент у нас "событийный", а сервер "процедурный".
то есть все построено задом наперед.
тогда да.
лочим список коннектов, засылаем клиентам мессаджи и разлочиваем.
если же сервер посторить как строят его нормальные герои (ожидание запроса->обработка->посылка ответа ), то лочить ничего не надо.
все происходит либю в OnExecute, либо в диспетчерах прикладных команд.

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

Сергей М. (2009-09-07 15:09:00) [89]

> без всяких локлистов и прочей ерунды

В мультипоточном сервере без lock-тряхомудии вряд ли обойтись)
Другой вопрос - она нада ли автору, мультипоточность та самая ..
Впрочем, он и сам не знает.

Медвежонок Пятачок (2009-09-07 14:57:00) [90]
правильная конфигурация:
сервер постоянно читает запросы клиентов.
получив запрос клиента, отправляет ему ответ, затем снова читает/ждет следующий запрос.

рассылка всем клиентам сообщения по инициативе сервера:
сервер получает текст сообщения от администратора и ничего никуда не посылает. Запоминает его и ждет, когда клиент запросит " А нет ли для меня какого-нить сообчения?"
Получив подобный запрос клиента, сервер отдаети ему сообщение прямо в обработчике команд, без всяких локлистов и прочей ерунды.

Сергей М. (2009-09-07 14:12:00) [91]

> про ресурсы ему еще рано

Тогда и делать ему пока нефига в индейских серверах. Не по сеньке шапка.
Есть TServerSocket, есть stNonBlocking - там ему "было проще всё, ну или понятней".
Какого лешего ему понадобилось лезть в индейские мультипоточные блокирующие дебри - до сих пор не понятно.
Было бы хотя бы вразумительное обоснование выбора Инди - был бы тогда и стимул вдалбливать ему про синхронизацию и прочую мультипоточную требуху. А так - что о стенку горох)

Сергей М. (2009-09-07 14:04:00) [92]

> что такое TIdPeerThread я не знаю, у меня такого нет

В 10-ке элементами этого списка явл-ся объекты класса TIdContext

Медвежонок Пятачок (2009-09-07 14:04:00) [93]
про ресурсы ему еще рано.
он кажется самого главного не понял:
если хочется, чтобы сервер имел возможность отправки сообщения в произвольный момент времени, то клиент такого сервера должен постоянно висеть в процедуре чтения буфера и ни на что иное не отвлекаться.
При этом он теряет возможность отправлять на сервер что-либо по своей инициативе.
Причем на все время своей сессии.

Сергей М. (2009-09-07 13:57:00) [94]

> Ну вот Server.Contexts.LockList а дальше что?

Ну и что толку тебе объяснять про "дальше что", если межпоточная синхронизация и защита ресурсов для тебя что новые ворота ?

Сергей М. (2009-09-07 13:51:00) [95]

> Ну нету никакого протокола

Ты прикидываешься или где ?

Как это "нету" ?

А это, к примеру, что по-твоему

> 'Welcame'

?

Почему именно "велцаме" у тебя фигурирует, а не "Здарофф, чувак ! Ет я, сервер, с тобой разговариваю" ?

Медвежонок Пятачок (2009-09-07 13:48:00) [96]
Ну нету никакого протокола.

У тебя ничего не получится.

Zalm (2009-09-07 13:45:00) [97]

> Ты вообще осознаешь, что работу с каждым из своих клиентов
> IdTCP-сервер осуществляет в отдельном дополнительном треде
> ?

это да, это я знаю.
> почему не выполняешь обязательную синхронизацию доступа
> к потоконебезопасным ресурсам, таким как, например, массив
> Clients, переменную Clients_count ?

не знаю, я такого раньше не делал, проблем как мне казалось из-за этого не было. да и как это синхронизацию я не знаю, я с этим не сталкивался к сожалению

Zalm (2009-09-07 13:39:00) [98]
Ну нету никакого протокола. В коде же видна идея как осуществляется обмен. При подключении "зарегистрировали" клиента, и всё, потом другой клиент подключается, такая же процедура, если они вводят один и тот же индекс, они получаются в паре, и сервер сразу передает между ними абсолютно всё что шлют (текст). Клиенты к этому серверу-посреднику обратиться никак не могут, ибо незачем.

> За каким тебе понадобились хендлы, если у тебя есть список
> уникальных объектов IdTCP.Server.Connections, каждый из
> которых отражает контекст соединения сервера с одним из
> его активных клиентов ?

а как записывать какие-то данные о клиенте что бы потом знать кто с кем в паре? Записать хендл мне показалось более целесообразно так как я видел функцию BindingByHandle, я подумал что можно по обработчику пробиться до сокета который он обрабатывает. Но идея завалилась.
А толку записать порт и адрес как вы говорили? что мне потом с ними делать?

> > LockList в котором уже я ничего не нашелЧто и где ты искал
> из того что не нашел ?

Ну вот Server.Contexts.LockList а дальше что? есть Items[index:integer]:pointer, это единственное что вызывает какое-то внимание, но сделать тоже ничего не получается с этим. Так что чем может помочь этот LockList я не понимаю, и вы подсказать не можете.

видел кусок из примера для инди 9

List := tcpServer.Threads.LockList; try for Count := 0 to List.Count -1 do try TIdPeerThread(List.Items[Count]).Connection.WriteLn(Msg); except TIdPeerThread(List.Items[Count]).Stop; end; finally tcpServer.Threads.UnlockList; end;
Они себе в переменную типа TList копируют себе этот LockList и рассылают всем сообщение. ТОлько что такое TIdPeerThread я не знаю, у меня такого нет. У них есть еще IdThreadMgrDefault1: TIdThreadMgrDefault; это в описании, тоже не знаю что это, у меня ткого нет.
Вобщем жаль что не хотите ничего конкретного подсказать.

Сергей М. (2009-09-07 13:36:00) [99]

> Zalm

Ты вообще осознаешь, что работу с каждым из своих клиентов IdTCP-сервер осуществляет в отдельном дополнительном треде ?
Судя по

> У TServerSocket было проще всё, ну или понятней

ты обязан это осознавать, ибо в режиме stThreadBlocking TServerSocket работает точно так же как и IdTCP-сервер.
Если осознаешь, то почему не выполняешь обязательную синхронизацию доступа к потоконебезопасным ресурсам, таким как, например, массив Clients, переменную Clients_count ?

Anatoly Podgoretsky (2009-09-07 13:24:00) [100]
> Zalm (07.09.2009 12:57:47) [47]

Так вопросы задаются, потому что от тебя не поступило полной информации,
если не ты, то мы.

Страницы: < 1 2 3 4 5 6 7 8 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »