Может ли кто-нибудь сказать мне, что более стабильно? Я знаю, что у каждого есть свои преимущества и недостатки. Но какой из них лучше для http и т. Д.?Indy или ICS или?
В моей предыдущей заявке я использовал indy9, но меня это не устраивало, так как иногда я получал странные ошибки.
Может кто-нибудь порекомендовать?
Я использую Indy в большом количестве проектов. Я использовал как 9, так и 10 в основном как HTTP-сервер и прокси. Проекты получают очень интенсивный трафик в разы (HTTP). Инди никогда меня не подводил. Он работает очень стабильно.
Но у меня также были некоторые «странные» ситуации, когда мне приходилось углубляться, чтобы найти основную проблему. Мне также не нравится, как Indy имеет тенденцию обрабатывать множество вещей за исключениями. В общем, мне больше нравится стиль кодирования ICS. Но позвольте мне пойти в ICS.
ICS использует неблокирующие сокеты, в то время как Indy использует блокировку. Хотя неблокирование в порядке и, кажется, лучше с первого взгляда, я нашел его раздражающим во многих ситуациях. Проблема в том, что естественный поток кода теряется из-за функций обратного вызова. Это затрудняет запись процедурных типов библиотек. Кроме того, мне не нравится, как все обрабатывается через сообщения. Для меня это становится беспорядочно реальным, когда смешивается с многопоточным. В наши дни многопоточность является основной.
Так что, хотя мне нравится стиль кодирования и качество кода в ICS, я предпочитаю простоту использования и режим блокировки Indy. То, что вам больше нравится, зависит от вас, но обе библиотеки являются зрелыми и стабильными.
Это мои два цента.
Я использовал Indy 9 и 10 для TCP, HTTP и FTP с очень небольшим количеством проблем. ICS - тоже хороший выбор. Он не блокирует, что изменит его использование.
Я не использовал его, но я слышал хорошие вещи о Synapse, который также блокирует.
Какая из них лучше всего зависит от конкретного варианта использования, но я был недоволен indy как клиент-клиент, и ICS оказался именно тем, чем я нуждался в этом, с гораздо меньшими случайными причудами.
Обратите внимание, что он не блокирует, поэтому это не просто замена.
Я использую Indy 9 для стабильного, выпущенного, производственного кода более чем 1 миллиону пользователей и никогда не получал никаких странных ошибок.
Я также использую как 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 всегда находится на стадии бета-тестирования. Иногда вам нужно работать с ночными сборками.
Я бы сказал, что ответ зависит от того, что вы хотите делать с Интернетом. Indy прекрасно, если вы готовы принять участие в понимании того, как это работает, и очень способны. ICS - это другое дело, и я использовал его для многих систем связи. Но для ежедневного «захвата файла или отправки электронной почты», когда вы хотите выполнить основную задачу, я почти всегда использую Clever Components Internet Suite, поскольку вы просто создаете компонент, задаете параметры, и он работает. Набор довольно обширен и получает полезные обновления.
Мы тестируем Indy10 IdTCPClient для получения видеопотока с удаленного сервера, все в порядке. Но когда он получает поток, в то же время он отправляет некоторые данные на сервер, через некоторую минуту полученные данные потока начинают потерять байты данных. Мы используем инструмент sniffer для отслеживания этой проблемы, подтвердили, что IdTCPClient потерял несколько байтов в потоке получения.
Итак, мы тестируем Indy9.018, та же проблема возникла, но несколько раз VS. Indy 10.
Хотя я также выступаю за Инди, я считаю, что экзамены ICS превосходят. Специально Indy10 –
Полностью согласен. Indy10 очень плох на примерах. – Runner
@ Runner Просто посмотрите на SO, есть еще проблемы с выпуском проблемы Indy, чем есть ICS. Вы будете судьей, что более стабильно. –