Инди или ICS или?

Question

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

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

Кто-нибудь может порекомендовать один?

Answer 1

Я использую Indy во многих проектах. Я использовал 9 и 10 в основном как HTTP-сервер и прокси. Временами проекты получают очень интенсивный трафик (HTTP). Инди никогда не подводила меня. Работает очень стабильно.

Но у меня также были некоторые "странные" ситуации, когда мне приходилось копать глубже, чтобы найти основную проблему. Мне также не нравится, как Indy имеет тенденцию обрабатывать множество вещей через исключения. Вообще мне больше нравится стиль кодирования ICS. Но позвольте мне перейти на ICS.

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

Так что, хотя мне нравится стиль кодирования и качество кода в ICS, я предпочитаю простоту использования и режим блокировки Indy. То, что вам нравится больше, зависит от вас, но обе библиотеки зрелые и стабильные.

Это мои два цента.

Answer 2

Я также использую Indy и ICS.

Большую часть времени я предпочитаю Indy, потому что реализация последовательных типов протоколов с ним очень проста (запрос выполняется в своем собственном потоке, так что вы просто читаете / пишете в соединение, очень просто). Использование Indy требует глубоких знаний о потоках и синхронизации. В отличие от Runner, мне нравится, как Indy использует исключения для обработки «исключительных» вещей, потому что это позволяет мне сконцентрироваться на нормальном потоке протокола (я использую блоки try-finally, чтобы убедиться, что я освобождаю ресурсы).

Я также использовал ICS в приложении, где Indy просто не удался: я использовал его для приложения, которое реализует прокси TCP / IP. Использование ICS было проще из-за его неблокирующей природы. Мне удалось «прокси» протоколы TCP / IP, о которых я ничего не знаю, поэтому я понятия не имею, как байты будут перетекать с одного конца на другой. Indy потерпел неудачу в этом сценарии, потому что в Indy вы читаете эфир или пишете, вы не можете делать и то и другое одновременно. Использование ICS для реализации протокола последовательного типа представляет собой небольшую боль: вам, по сути, нужно использовать логику конечного автомата, разбивать протокол на мелкие биты, постоянно устанавливать флаги, чтобы вы знали, где вы находитесь в протоколе. Большой плюс: Франсуа Пиетт, автор ICS, активен и очень полезен на многих форумах и в списках рассылки, и очень быстро поможет со всем, что связано с ICS.

Для меня, если мне нужно что-то сделать с TCP / IP, путь решения очень прост: это можно сделать с помощью Indy? Тогда это Инди. Если это не может быть сделано с Indy, то это будет сделано с ICS!

Answer 3

Я использовал Indy 9 и 10 для TCP, HTTP и FTP без особых проблем. ИКС тоже хороший выбор. Это не блокировка, которая изменит то, как вы ее используете.

Я не использовал его, но слышал хорошие слова о Synapse , который также блокирует.

Answer 4

Мы тестируем Indy10 IdTCPClient для приема видеопотока с удаленного сервера, все нормально.Но когда он получает поток, в то же время он отправляет некоторые данные на сервер, через несколько минут полученные данные потока начинают терять байты данных.Мы используем инструмент анализатора для отслеживания этой проблемы, подтвердил, что IdTCPClient потерял несколько байтов в принимающем потоке.

Итак, мы тестируем Indy9.018, та же проблема случалась, но несколько раз VSIndy 10.

Answer 5

Помните, что Indy всегда находится в стадии бета-тестирования. Иногда вам нужно работать с ночными сборками.

Answer 6

Я бы сказал, что ответ зависит от того, что вы хотите сделать с Интернетом. Инди хорошо, если вы готовы понять, как она работает, и очень способна. ICS - это другой взгляд на вещи, и я эффективно использовал его для систем с множеством соединений. Но для повседневной работы типа «захват файла или отправки по электронной почте», где вы хотите выполнить основную задачу, я почти всегда использую Clever Components Internet Suite , поскольку вы просто создаете компонент установить параметры, и это работает. Пакет является довольно полным и получает полезные обновления.

Answer 7

Я использую Indy 9 для стабильного, выпущенного, производственного кода для более чем 1 миллиона пользователей, и никогда не получал никаких странных ошибок.

Answer 8

Какой из них лучше, действительно зависит от конкретного случая использования, но я был недоволен инди в качестве http-клиента, и в результате ICS оказался именно тем, что мне было нужно, с гораздо меньшим количеством случайных причуд.

Обратите внимание, что он не блокирует, так что это не просто замена.