Wiki: современное состояние Delphi сторонних библиотек компонентов TCP/IP

Ответ 1

Изменить: Резюме моего прошлого опыта с Indy и комментариев (спасибо Eugene, Marjan) (пожалуйста, обновите текущее состояние Indy):

Pro:

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

Con:

• версия с Delphi не всегда была самой стабильной; загрузка из источников обычно требовалась для получения стабильной сборки
• (в среднем время) много дублирования кода, который теперь находится в Delphi (но Indy требует совместимости со старыми версиями Delphi)
• не все компоненты TCP/IP были обновлены (например, тогда клиентский компонент POP3 не поддерживал некоторые базовые команды POP3)
• совместимость версий была болью: обновление от одной версии Indy до другого может быть очень трудоемким.
• Я неоднозначно отношусь к обработке исключений и антизамерзанию в Indy, хотя я привык к этому, он все еще выглядел несколько неестественным.
• нарушаются изменения между обновлениями сборки; ifdefs, необходимые для размещения этих
• Нечеткий статус релиза, если он вообще отсутствует, никакие RC в течение длительного времени, получение соединительной линии может сделать вашу локальную копию нестабильной.

Ответ 2

ICS - пакет интернет-компонентов

ICS - см. www.overbyte.be. Открытый исходник Франсуа Пьетте. Для меня это всегда была альтернативой номер 1 для Indy. Это самый интересный пункт продажи: он упрощает использование асинхронного материала, а async, похоже, ближе к программированию сокетов "голый металл".

Я использовал его для создания довольно сложного прокси-сервера VNC, где сам прокси-сервер (сервер) построен с ICS, а клиенты - это смесь Indy и ICS. В периоды высокого спроса прокси обрабатывает около 100 одновременных подключений и около 10 одновременных сеансов экрана VNC. Он съедает в среднем 5 мбит/с, обрабатывает соединения через два разных интернет-соединения. Я не думаю, что 100 + 10 является пределом, потому что сервер обрабатывает это без каких-либо проблем, а использование ЦП слишком мало, чтобы упомянуть.

Плюсы:

• Работает асинхронно
• Немного легче для новичков, потому что ему не нужны потоки.
• Поддерживает большое количество протоколов.

Минусы:

• Используется для обмена сообщениями Windows. Мне просто не нравится это.
• Асинхронное поведение упрощает выполнение большинства протоколов (поскольку большинство протоколов находятся в форме отправки/получения ответа). Это не должно иметь большого значения для большинства людей, поскольку ICS предлагает готовые реализации для наиболее часто используемых протоколов.

Все, что было сказано, я не использовал ICS в течение очень долгого времени, я не доволен всеми колокольчиками и свистами. Это CW, поэтому, пожалуйста, отредактируйте и расширьте!

Ответ 3

Я использовал Indy с 2003 года для своей собственной инфраструктуры связи TCP. Он прочный, у меня версия, используемая с Delphi 2007, а другая с Delphi 2010, если вы правильно обрабатываете threadng, нет необходимости использовать материал для защиты от замораживания, и у меня есть последовательная обработка исключений на клиенте и сервере реализуя мою собственную оболочку вокруг этого.

Вы можете загрузить его здесь (http://www.csinnovations.com/framework_delphi.htm) - найдите устройства Tcp, в основном AppTcpServerUnt и AppTcpClientUnt.

Ответ 4

Я бы настоятельно рекомендовал "Умный интернет-люкс" , это, безусловно, лучший разработанный и написанный набор коммуникационных компонентов. Это не бесплатно и так не так хорошо известно, но стоит исследовать.

Pro:

• хорошо спроектированный и написанный
• содержит много components и реализует различные протоколы.
• поддерживает широкий набор версий Delphi (включая 2007 и XE).
• Поддержка SSL
• зрелый продукт, поскольку история выпуска указывает

Con:

• не открытый источник

Ответ 5

Ответ действительно зависит от многих факторов и ваших требований, таких как

• какие слои необходимы (TCP, SSL/TLS, протоколы уровня приложений)
• нужен ли вам клиент или сервер (сервер представляет собой гораздо более сложную задачу)
• рассчитываете ли вы оплаченные варианты.

В целом, не так много (положительных) произошло за 18 месяцев или даже через 3 года, поскольку большинство разработчиков рассматривают .NET как основную платформу разработки.

Умный интернет-люкс, упомянутый в другом ответе, и DevArt SecureBridge получили некоторые новые функции.

Наш SecureBlackbox предлагает поддержку самых продвинутых функций (помимо собственных SSL/TLS): IPv6, HTTPS-прокси с базовым, дайджестом и NTLM-аутентификацией (начиная с SecureBlackbox 9), международных доменных имен (начиная с SecureBlackbox 9), DNSSEC, управления пропускной способностью и т.д.

Протоколы уровня приложений, поддерживаемые SecureBlackbox, - это HTTP (клиент и сервер), WebDAV (клиент и сервер), FTP (клиент и сервер), SSH и SFTP (клиент и сервер), клиенты SMTP и POP3, DNS-клиент, AS2 и AS3. Все протоколы (помимо SSH и SFTP, конечно) имеют полную поддержку SSL/TLS.

Список поддерживаемых протоколов можно найти на странице Packages. Поддерживаемые функции протокола перечислены на странице технической спецификации для каждого пакета.

Ответ 6

Вы можете использовать более высокий уровень протокола, например HTTP, потому что:

• Более брандмауэр и VPN-интерфейс;
• Он хорошо документирован и известен как хороший протокол;
• У него уже есть версия HTTPS,
• Он имеет очень низкую нагрузку на строку TCP/IP;
• Он готов к использованию в среде AJAX (если вам это нужно в будущем);
• Microsoft уже настроила низкоуровневую настройку для вас в современной версии Windows.

В этом случае вы можете взглянуть на два класса с открытым исходным кодом, работающие с Delphi 6 до XE:

THttpApiServer, который реализует HTTP-сервер, используя быстрый сервер режима ядра http.sys:

• API-интерфейс HTTP-сервера позволяет приложениям общаться через HTTP без с использованием Microsoft Internet Information Server (IIS). Приложения могут регистрироваться получать HTTP-запросы для определенных URL-адресов, получать HTTP-запросы и отправлять HTTP-ответы. API-интерфейс HTTP-сервера включает поддержку SSL, чтобы приложения могут обмениваться данными по защищенным HTTP-соединениям без IIS. Это также предназначенный для работы с портами завершения ввода/вывода.
• API-интерфейс HTTP-сервера поддерживается в операционных системах Windows Server 2003 и в Windows XP с пакетом обновления 2 (SP2). Имейте в виду, что Microsoft IIS 5 работающий в Windows XP с пакетом обновления 2 (SP2) не может совместно использовать порт 80 с другим HTTP-протоколом приложения, выполняемые одновременно.

TWinHTTP, который обрабатывает клиентский HTTP/1.1 запрос с использованием API WinHTTP:

• HTTP-службы Microsoft Windows (WinHTTP) предназначены для среднего уровня и  серверные серверные приложения, которым требуется доступ к стеку HTTP-клиента;
• Быстрее, чем предыдущий WinINet API.

Результирующая скорость очень хорошая (особенно сервер), и вы будете полагаться на реализацию Microsoft. Первый - это ядро ​​IIS, а второе - в последних версиях Internet Explorer.

Ответ 7

Работа с компонентами NetMaster (путь!) в старых версиях Delphi (2! 3! 4!)

Была ли какая-то работа с Инди, но у нее было и неестественное чувство (на самом деле я бы описал ее скорее как громоздкий)

Наткнулся на Synapse, когда я искал только легкую оболочку вокруг сетевого API Windows,

И затем вновь открылся простой старый TTcpClient/TTcpServer. Это Delphi собственная обертка вокруг winsock! Я использую их блокировку с выделенным наследником TThread для каждого TTcpClient и позволяю TTcpServer делать потоки и выполнять всю работу в DoAccept, см. здесь для пример.

Это, теперь, дало мне ощущение рок-музыки, которое мы ищем. Если вы хотите поддерживать большую нагрузку, я бы попытался создать диспетчер потоков, который обрабатывает несколько сокетов/соединений в потоке или имеет два набора потоков: несколько, которые прослушивают большее количество "бездействующих" соединений, а другие, которые обрабатывают меньшие "активные" соединения, коммутирующие соединения между потоками в зависимости от того, обрабатывается ли запрос или ответ. (например, HTTP Connection: keep-alive)