Как передать сообщение зная IP?

[Максим]

Попытался разобраться с lnet, для меня что-то слишком сложно, документации нет

Да ну, а это, это, это что?

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

Прежде, чем открывать примеры, компоненты надо бы поставить.

[alexey38]

Для почты есть API - MAPI.

Код: Выделить всё

MAPILogon(0,nil,nil,MAPI_NEW_SESSION,0,@w);
MAPISendMail(w,Application.Handle,mm,MAPI_DIALOG,0);
MAPILogoff(w,0,0,0);


Если почтового клиента не закрывать, то он в трее как раз пишет о том, что пришло письмо. И утилит для этого целый вагон.

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

[VinSS]

Шифровать смысла нет, посылать надо только факт прихода задания. Завтра еще поковыряюсь, сообщу о результатах.

[alexey38]

Если серверная часть знает своих клиентов, то будет правильней ей отсылать по UDP периодически сообщения о том, что есть новые вещи.
Клиент после получения UDP сообщения уже по TCP создает соединение и запрашивает новые сообщения, которые по этому же соединению сервер передает, на что клиент подтверждает и сервер снимает у себя признак не переданных данных и перестает слать этому клиенту UDP сообщения, до появления новой информации.
В API есть как раз функции типа socket, connect, recv, send. Контроль через Event, только они какие-то там специальные.

[VinSS]

Не получается запустить примеры их LNet, они все хотят LCLBase>=1.0.1, пытаюсь поставить из самого лазаря, получаю: пакет lclbase не имеет процедуры "Register", даже если согласиться, установки все равно не произойдет.

[SSerge]

Если серверная часть знает своих клиентов, то будет правильней ей отсылать по UDP периодически сообщения о том, что есть новые вещи.

С точки зрения администрирования сети, входящие несанкционированные соединения, тем более по UDP, на станциях должны быть закрыты. К тому же, сам протокол не имеет средств определения, дошли куда то пакеты или не дошли. И, вот у вас, скажем 200 станций. На каждую надо прописать правила, разрешающую трафик на нужный порт, а на самом сервере - весь пул адресов для вашей программы, куда он будет рассылать сообщения. А сервер - один. Не проще ли все входящие организовывать на нем, а не на периферии?

[alexey38]

Не получается запустить примеры их LNet, они все хотят LCLBase>=1.0.1, пытаюсь поставить из самого лазаря, получаю: пакет lclbase не имеет процедуры "Register", даже если согласиться, установки все равно не произойдет.

Сколько раз убеждался, что использование компонентов и библиотек без понимания физического уровня решаемой задачи приводят к большим сложностям, ошибкам и прочим проблемам.
Самое надежное и быстрое, взять API (WinAPI если вы работаете под виндой) и написать задачу на низком уровне (Socket). На это при грамотном подходе и с использованием инета уйдет 1-2 дня, и вы получите рабочее решение примерно в 200 строк кода. После освоения API и понимания, как на самом деле происходит передача данных по сети (любая передача идет через Socket, в т.ч. DCOM, http), можно заниматься подбором библиотеки, когда глядя в ее код будет понятно, что она делает и зачем, т.к. библиотека должна помогать, а не мешать решению задачи.

Добавлено спустя 56 минут 24 секунды:

С точки зрения администрирования сети, входящие несанкционированные соединения, тем более по UDP, на станциях должны быть закрыты. К тому же, сам протокол не имеет средств определения, дошли куда то пакеты или не дошли. И, вот у вас, скажем 200 станций. На каждую надо прописать правила, разрешающую трафик на нужный порт, а на самом сервере - весь пул адресов для вашей программы, куда он будет рассылать сообщения. А сервер - один. Не проще ли все входящие организовывать на нем, а не на периферии?

Весь вопрос вопрос знает ли сервер своих клиентов (в смысле IP), поэтому такие сообщения не будут несанкционированными. Сами по себе входящие пакеты ни UDP, ни TCP не опасны, с позиции безопасности. Опасность может заключаться в том, что стоит несанкционированный софт, получающий несанкционированные пакеты. Но если наш UDP будет прослушиваться конкретной программой, то другая программа не может это сделать. Так что опасности это не добавляет. А так как известен и клиент и сервер, то на уровне firewall можно это явно прописать. Кстати, с позиции безопасности нужно в первую очередь защищать сервер, а не рабочие станции, в т.ч. защищать сервер от несанкционированных или слишком частых пакетов.

Если проверять сообщения нужно редко (например, 1 раз в несколько секунд и клиентов мало), то можно выбрать TCP. Но если клиентов например 10 000, а новые сообщения нужно проверять каждые 100 мс, то выбор TCP просто положит сеть и сервер непрерывными запросами. UDP хорош тем, что пойдет только пакет с сообщением и все, а пустых запросов вообще нет. Сервер будет знать о том, что сообщения не дошли, т.к. я предлагаю после передачи первичного UDP организовать TCP соединение, в результате чего сервер узнает, что клиент получил сообщение. Соответственно, если клиент не вышел на связь, значит клиент не получил сообщение.

[VinSS]

Самое надежное и быстрое, взять API (WinAPI если вы работаете под виндой) и написать задачу на низком уровне (Socket).

Где почитать?

Добавлено спустя 25 минут 1 секунду:
На самом деле теория пока бесполезна
Я не могу банально сделать на одном компе форму с окном с текстом, который надо переслать, и ИП компа и порта, куда этот текст надо отправить. А на другом просто окно куда текст приходит и все.

[alexey38]

Самое надежное и быстрое, взять API (WinAPI если вы работаете под виндой) и написать задачу на низком уровне (Socket).

Где почитать?

Добавлено спустя 25 минут 1 секунду:
На самом деле теория пока бесполезна
Я не могу банально сделать на одном компе форму с окном с текстом, который надо переслать, и ИП компа и порта, куда этот текст надо отправить. А на другом просто окно куда текст приходит и все.

winsock.pp
функции типа socket, connect, recv, send
Я читаю в help по Win32 которая есть в дельфях, в визуале и наверное есть в инете.
Набрал в яндексе "winsock socket" и получил http://www.realcoding.net/article/view/1833

[VinSS]

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

[Vadim]

VinSS
Все проблемы начинаются с нечётко поставленой задачи.

[alexey38]

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

Я Вам указал на первую же ссылку, которую нашел яндекс. Естественно не бывает так, чтобы там была реализация именно Вашей задачи.
У них пример консольный, а у Вас будет не консольный. И что? Вам нужно ознакомиться с технологией передачи по сети, понять как туда-сюда ходят пакеты.
Нужен пользовательский интерфейс - делайте, никто не мешает.

Совет сразу, Вам скорее всего потребуется многопоточное приложение. Работа по сети, хоть просмотр файлов в сетевом каталоге, хоть ожидание, прием или передача данных - это все занимает время. Один поток - это пользовательский интерфейс. Другой (на клиенте) - это передача и прием. Для синхронизации между ними используйте критические секции. Чтобы ожидание пакетов не занимало процессорного времени используйте Event, которые специальные есть для сокетов.

На сервере возможно придется создавать поток под каждого клиента, м.б. на период обмена сообщениями, а м.б. сразу при инициализации.

По существу ничего сложного. Обмен по сети у Вас займет порядка 100 строк кода. Все остальное - это Ваш прикладной уровень и пользовательский интерфейс.

[olegy123]

Если нужно многопоточность, а не знаете как, то существует два варианта:
1) используем socket, lnet, synapse. Кладем Timer, время опроса. В OnTimer прописываем чтение из сокета. Лучше подходит UDP.
2) используем Indy, он сам создает потоки под каждый коннекшен.