Может ли кто-нибудь сказать мне, что более стабильно? Я знаю, что у каждого есть свои преимущества и недостатки. Но какой из них лучше для http и т.д.?
В моем предыдущем приложении я использовал indy9, но меня это не устраивало, поскольку иногда я получал странные ошибки.
Может кто-нибудь порекомендовать один?
Я использую Indy в большом количестве проектов. Я использовал как 9, так и 10 в основном как HTTP-сервер и прокси. Проекты получают очень интенсивный трафик в разы (HTTP). Инди никогда меня не подводил. Он работает очень стабильно.
Но у меня также были некоторые "странные" ситуации, когда мне приходилось рыть глубоко, чтобы найти основную проблему. Мне также не нравится, как Indy имеет тенденцию обрабатывать множество вещей за исключениями. В общем, мне больше нравится стиль кодирования ICS. Но позвольте мне пойти в ICS.
ICS использует неблокирующие сокеты, в то время как Indy использует блокировку. Хотя неблокирование в порядке и, кажется, лучше с первого взгляда, я нашел его раздражающим во многих ситуациях. Проблема в том, что естественный поток кода теряется из-за функций обратного вызова. Это затрудняет запись процедурных типов библиотек. Кроме того, мне не нравится, как все обрабатывается через сообщения. Для меня это становится беспорядочно реальным, когда смешивается с многопоточным. В наши дни многопоточность является основной.
Поэтому, когда мне нравится стиль кодирования и качество кода в ICS, я предпочитаю простоту использования и режим блокировки Indy. Что вам нравится больше, зависит от вас, но обе библиотеки являются зрелыми и стабильными.
Это мои два цента.
Я также использую как Indy, так и ICS.
В большинстве случаев я предпочитаю Indy, потому что внедрение последовательного типа протоколов с ним очень просто (запрос запускается в нем собственным потоком, поэтому вы просто читаете/пишите на соединение, очень просто). Использование Indy требует глубокого знания потоков и синхронизации. В отличие от Runner мне нравится, как Indy использует Exceptions для обработки "исключительных" вещей, потому что это позволяет мне сосредоточиться на нормальном потоке протокола (я использую блоки try-finally, чтобы удостовериться, что я освобождаю ресурсы).
Я также использовал ICS в приложении, где Indy просто не удалось: я использовал его для приложения, которое реализует прокси TCP/IP. Использование ICS было проще из-за неблокирующего характера. Я смог прокси-протоколы TCP/IP, о которых я ничего не знаю, поэтому я понятия не имею, как байты будут перетекать с одного конца на другой. Indy потерпел неудачу в этом сценарии, потому что в Indy вы читаете эфир или пишете, вы не можете делать оба одновременно. Использование ICS для реализации протокола последовательного типа немного больно: вам по существу нужно использовать логику состояния машины, тормозить протокол небольшими битами, удерживать флаги, чтобы вы знали, где находитесь в протоколе. Большой плюс: Франсуа Пьетте, автор ICS, активно и очень полезно на нескольких форумах и в списке рассылки, и очень быстро помогает в решении любых вопросов, связанных с ICS.
Для меня, если мне нужно что-то делать с TCP/IP, путь решения очень прост: можно ли это сделать с помощью Indy? Тогда это Indy. Если это не может быть сделано с Indy, то это будет сделано с помощью ICS!
Я использовал Indy 9 и 10 для TCP, HTTP и FTP с очень небольшим количеством проблем. ICS - тоже хороший выбор. Он не блокирует, что изменит способ использования.
Я не использовал его, но я слышал хорошие вещи о Synapse, который также блокирует.
Помните, что Indy всегда находится в стадии бета-тестирования. Иногда вам нужно работать с ночными сборками.
Мы тестируем Indy10 IdTCPClient для получения видеопотока с удаленного сервера, это нормально. Но когда он получает поток, то в то же время он отправляет некоторые данные на сервер, через какую-то минуту полученные данные потока начинают потерять байты данных. Мы используем инструмент sniffer для отслеживания этой проблемы, подтвердили, что IdTCPClient потерял несколько байтов в потоке получения.
Итак, мы тестируем Indy9.018, та же проблема возникает, но несколько раз VS. Indy 10.
Какой из них лучше всего зависит от конкретного варианта использования, но я был недоволен indy в качестве http-клиента, и ICS оказалась именно тем, чем я нуждался в этом, с гораздо меньшими случайными причудами.
Обратите внимание, что это не блокировка, поэтому это не просто замена.
Я использую Indy 9 для стабильного, выпущенного, производственного кода более чем 1 миллиону пользователей и никогда не получал никаких странных ошибок.
Я бы сказал, что ответ зависит от того, что вы хотите делать с Интернетом. Indy прекрасно, если вы готовы принять участие в понимании того, как это работает, и очень способны. ICS - это другое дело, и я использовал его для многих систем связи. Но для повседневной работы "захватить файл или отправить электронную почту", где вы хотите выполнить основную задачу, я почти всегда использую Clever Components Internet Suite, поскольку вы просто создаете компонент, установите параметры, и он будет работать. Набор довольно обширен и получает полезные обновления.