SOFT FOR YOU,

делаешь чтоли тестовое задание для устройств на работу?))

Если нужно использовать либы только из стандартной поставки Delphi, то используй Indy, а именно (как говорилось выше) TIdTcpServer/TIdTcpClient. Напрямую с байтами тоже можно работать, если сильно хочется.

У TIdTcpServer делаешь обработку контекста, этого достаточно для идентификации сессии клиента. О клиенте напрямую ты сможешь узнать только его IP и порт подключения, все остальные параметры (нетбиос-компа, имя юзера и т.д.) нужно сообщать клиентом серверу самостоятельно. Из приятного - у контекста соединения на сервере есть поле Data, в котором ты сможешь хранить все дополнительные данные по соединению с данным клиентом (создаешь экземпляр своего нужного класс, присваиваешь ссылку на него в Data, потом при разрыве сессии не забудь память освободить).
Из приколов Indy это необходимость использования Sleep(0) в обработке контекста на сервере, иначе сервер при 0 кол-ве соединений может занимать 100% процессорного времени (это происходит, когда хотя бы один клиент подключается, потом отключается, и по факту соединений становится 0).

Да, лично я считаю вывод каждого события сразу в TMemo странным решением))) Лучше хранить лог в каком нить TStringList, в UI главного потока лично я вывожу не чаще 1 го раза в секунду

SOFT FOR YOU,

отправка данных клиентом серверу - IdTCPClient.IOHandler.Write
аналогично чтение :-) только я выставляю таймаут на чтение 1 мс, и на всякий случай дополнительно проверяю наличие данных в буфере приема перед чтением

SOFT FOR YOU,

добавь на клиенте класс-очередь команд, например список типа "[команда][статус_отправки][статус_приема]"
отправил команду, установил статус [статус_отправки]
получил команду, нашел ее в своем списке очереди, отметил что получил, обработал как надо и потом удалил из очереди

На сервере все тоже самое, только там можно данные сессии с клиентом хранить в поле Data контекста

makhaonавторИз приколов Indy это необходимость использования Sleep(0) в обработке контекста на сервере, иначе сервер при 0 кол-ве соединений может занимать 100% процессорного времени (это происходит, когда хотя бы один клиент подключается, потом отключается, и по факту соединений становится 0).

Никогда за 15+ лет не видел такой проблемы.Учитывая специфику работы менеджера потоков Indy, весьма странно, что ты не встречался с такой проблемой. Вот тебе пример этой проблемы: http://www.sql.ru/forum/1076998/tidtcpserver-i-100-zagruzka-processora

SOFT FOR YOU,

нет, TidTcpClient у тебя один перманетный, т.е. в начале работы программы создал, в конце работы уничтожил.
Твоя задача периодически вызывать read / write у этого компонента. Я использую его внутри отдельного потока, который содержит как TidTcpClient, так и список команд для выполнения
А GUI уже считывает данные не с TidTcpClient, а с этого отдельного потока

SOFT FOR YOU,

Indy, как сказали на одном форуме - это синхронные блокирующие сокеты, они вообще не вписываются в событийную модель Windows. Соответственно как получить событие о поступлении данных, лично я не знаю :-) И поэтому пользуюсь вариантом, когда в отдельном потоке постоянно проверяю поступление данных. Зато у Indy есть плюс - код работает во всех ОС, включая Linux (компиляция под которые доступны с 10.2 Токио).

перед проверяй на наличие данных так:



Что касается поступления данных, не забывай - это протокол TCP, поэтому всё приходит исключительно в том порядке, в котором отправлено. Поэтому смело можешь придумать свой формат обмена, например каждая строка может иметь формат, как вариант :
{CMD:xxx}{DATA:данные_в_base64}{END}<EOL>
Парсируй на {CMD: и {END} , простор для фантазии неограничен :-)