Использую IdTCPServer и IdTCPClient. Необходимо сделать, чтобы чтение и запись в сокет происходило в разных потоках и на клиенте и на сервере. Для этого на клиенте кидаю IdTCPClient  на форму - через него пишу. Создаю поток, в нем создаю еще один IdTCPClient - через него читаю.  Получается, что на сервере создаются два потока. Для того, чтобы можно было обратиться к потоку и через него писать пытаюсь использовать делаю  следующим образом: 
1)Соединяюсь с сервером из основоного потока клиентcкого приложения и из потока, через который собираюсь читать.
2) Из главного потока приложения отправляю серверу значение idTCPClient.Socket.Binding.ID  - IdTCPClient-a из читающего потока.
3) На сервере в OnConnect для того, чтобы определить, в каком потоке нужно писать, перебираю ID соединений всех потоков: TIdContext(IdTCPServer.Contexts.LockList.Items[i]).Connection.Socket.Binidng.ID    и  сраниваю с принятым  значением от клиента. 

Почему - то значение Binding.ID  всегда = 0. Объясните, пожалуйста,  как вообще работать со связками.
 Да и может быть лучше как-нибудь по-другому организовать чтение и запись в разных потоках.

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

У меня стоит задача - осуществить чтение и запись в разных потоках :(

Не подскажите, где можно найти какую-нибудь инфу по bindings. 
На клиенте делаю так:
 

Вылетает "Access violation". Подскажите, в чем ошибка?

а SoCket создан?

Как я понимаю, когда я создаю IDTCPClient, socket тоже создается, а клиент у меня создан:

IdTCPClient:=TIdTCPClient.Create;

Я чего-т не допонял... А какое отношение имеет SoCket к IdTCPClient?

Socket - это IDTCPClient.Socket

Я просто код не весь вставил:


Добавлено через 6 минут и 18 секунд
А еще такой вопрос: 

Создаю IdTCPServer, ставлю обработчик OnExecute, в котором ничего не делаю. Подсоединяется клиент и все начинает тормозит, в диспетчере задач мой сервер юзает 99% ресурсов процессора, хотя ни сервер, ни клиент никакой информации не пишет\не читает. 
В чем прична?

что за изврат?
чем не устроило:

p.s. хоть бы хелп посмотрел.
св-ва BoundIP/BoundPort - это "исходящие" параметры клиента. 
а Host и Port - к чему подсоединяться

Это сообщение отредактировал(а) MetalFan - 19.5.2007, 11:49

Спасибо. 
Но как связывать то bindings?  ато  Access violation  и все...?

Sokolll, на кой тебе дались эти bindings???
указываешь порт, хост. делаешь коннект. что надо то еще?

Во-первых просто интересно, во-вторых, как писал, нужно организовать чтение и запись в разных потоках. А для того, чтобы определить на серере, в каком потоке надо писать, хотел использовать свойство bindings.ID, ведь как, я понимаю, его значение должно быть одинаковым и на клиенте и на сервере.

Так как с Bindings ничего не получилось, сделал так:
На клиенте сначала подключаюсь из читающего потока, затем из основного потока приложения.
При подключении на клиенте посылаю строку-идентификатор, состоящую из цифры 1 - для пишущего потока или цифры 2 - для читающего, и хэндла окна главной формы.
На сервере при подключении клиента читаю строку-идентификатор и присваиваю ее значению Connection.Tag.
Дальше проверяю, если 1-ый символ строки = '2' - значит это соединение с IdTCPCLient-ом чиатющего потока клиентского приложения - Exit;
Если '1' - значит это соедиенение с IdTCPClient-ом пишущего потока клиентсокого приложения и далее делаю следующее:
Надо определить в каком потоке писать (в потоке с Connection.Tag = '2......').
Перебираю Connection.Tag всех контекстов IdTCPServer-а   -  сравниваю Tag  cо строкой:  AContext.Connection.Tag только первый символ = '2'. При совпадении  в переменную типа Pointer присваиваю указатель на контекст.
Все. Теперь, если надо что-то послать на клиентское приложение, пишу в этом контексте.

Получилось замудренно, но работает

не самая хорошая идея использовать для идентификации клиента в сети хэндл формы приложения...
уж лучше раздавать ID при подключении сервером

Спасибо, так и сделал. Получилось проще и лучше.