INDY FTP -зависание

JohnS

Hi AllУ меня прога качает по FTP файлы . У всех все хорошо . Но как обычно на одной точке происходит зависание проги на закачке , а именно на idFTp.GET. Причем у клиентов ВЫДЕЛЕНКА !!!Скажем я могу сделать команду idFTP.get в потоке . Но как я отловлю и как СМОДЕЛИРУЮ зависание в локальной сетке !!!
24 ответа

JohnS

Ну вот , и никто не скажет доброго слова


JohnS

Не заслуживает.


JohnS

Не заслуживает.
Попытка вопроса незасчитана


JohnS

Попытка вопроса незасчитана
Ну есть места где он не плох, но в Дельфи это чужеродный экспонат.Я недавно делал NNTP сервер, довольно быстро отказался от него в пользу ICS - вот это другое дело, душа радуется.


JohnS

Я недавно делал NNTP сервер, довольно быстро отказался от него в пользу ICS - вот это другое дело, душа радуется.
Не пробовал. Задача возникала раз, но не в Win, щупал Indy и Synapse.


JohnS

Synapse он честный.


JohnS

Ну есть места где он не плох, но в Дельфи это чужеродный экспонат.Я недавно делал NNTP сервер, довольно быстро отказался от него в пользу ICS - вот это другое дело, душа радуется.
То есть INDY идуший с дистрибутивом Делфи , это чужой среди своих ???


JohnS

По идеологии да, но брали не что надо, а что дали.Поскольку FastNet погиб, а ICS не дали.


JohnS

То есть INDY идуший с дистрибутивом Делфи , это чужой среди своих ???
Не знаю, как насчет идеалогии, но то, что Indy - это непроходимый глюкодром - это факт.По поводу ftp - есть уже готовая реализация - посмотри в сторону WinInet.pasFtpGetFile, FtpPutFile и т.д.


JohnS

Не знаю, как насчет идеалогии, но то, что Indy - это непроходимый глюкодром - это факт.По поводу ftp - есть уже готовая реализация - посмотри в сторону WinInet.pasFtpGetFile, FtpPutFile и т.д.
Факт, факт, я знал об этом, но хотел лично убедиться.Если потоковые функции, типа файловых работают нормально, то все что чуть посложнее с нелинейной логикой, вроде как и работают, но как то не так.Лично убеждался на основе NNTP сервера, таких не хороших слов про него начитался в их форуме, так что уши покраснели.Все связано с тем, что используются блокирующие сокеты из мира Юникс и события только для информативных целей, а не для обработки.Делать что то многоточное просто не реально, поскольку каждому потоку по умолчанию назначается стек в 1 мегабайт и при 2000 потоков, памяти просто нет, это 2 гигабайта только под стек!А нелинейную логику на линейном программировании сделать конечно можно, но сложно и будут одни глюки.Другое дело ICS делался сразу на неблокирующих сокетах (но есть и блокирующие для особых случаев), требует только одного слушающего сокета, основан на событиях, запустил процесс и получишь управление в одном из обрабочиков, например в OnComplete, а сам занимайся своим делом. Никаких потоков и прочего. Соответсвенно никаких проблем с этим.Жалко, что ICS, в отличии от Indy не валялся на улице. Вот Борланд и подобрал его.У Борланда есть особая привычка, брать что попало, что лежит без присмотра и особенно это сильно видно на примерах генераторов отчетов, Интернет компонент и некоторого другого. Постоянные свистопляски вокруг этого. Вот кто может вспомнить сколько генераторов отчетов использовал Борланд? А сколько разных Интернет компонент? Это не благоприятствует стабильности продукта. Да и поддержка этих компонент никакая. Тот же Инди после включения в состав стал стремительно падать, сайт опаскудел и у меня впечатление, что все сейчас держится на энтузиастах и ухудшается на глазах. Еще как то Rave держится, но поддержка стала хуже.


JohnS

Да и еще - ICS не для тех, кто не понимает Drivent Event Model, тем более подходит Инди. Там же просто как с ReadLn/WriteLn - но шаг влево, шаг вправо растрел. Прыжок на месте провокация. На этой основе построить сложный сервер малореально и потребует неординарных усилий. Это уже не прокачка файлов и не чат, с их простой логикой.


JohnS

Ну вот , и никто не скажет доброго слова
Не жди добрых слов, хотя твой вопрос тривиальный.


JohnS

Делать что то многоточное просто не реально, поскольку каждому потоку по умолчанию назначается стек в 1 мегабайт и при 2000 потоков, памяти просто нет, это 2 гигабайта только под стек!
Вообще то в понятии многопоточного сервера - много изначально путанницы. Но, тем не менее, сам факт реализации этого подхода - заслуживает отдельного рассмотрения. И желательно - на примере известных зубров, сьевших на этом не одну собаку (apache или oracle). Как концепция листенера и рабочих процессов к примеру - в картинках
А нелинейную логику на линейном программировании сделать конечно можно, но сложно и будут одни глюки.
Стоп. А это из той оперы ? Линейное программирование - это вообще то сугубо математические методы оптимизации (к сетям то какое отношение ?)
У Борланда есть особая привычка, брать что попало, что лежит без присмотра и особенно это сильно видно на примерах генераторов отчетов, Интернет компонент и некоторого другого.
а) никто не заставляет их использовать - всегда можно безжалостно выброситьб) но начинающие - то про это не знают ;) Вот и попадаются каждый раз на бесплатный сыр. А с другой стороны - это не баг, а фича - не было бы сторонних компонент - было бы скучно ;)


JohnS

Вообще то в понятии многопоточного сервера - много изначально путанницы. Но, тем не менее, сам факт реализации этого подхода - заслуживает отдельного рассмотрения. И желательно - на примере известных зубров, сьевших на этом не одну собаку (apache или oracle). Как концепция листенера и рабочих процессов
Вот именно, что придется съесть не одну собаку.
Стоп. А это из той оперы ? Линейное программирование - это вообще то сугубо математические методы оптимизации (к сетям то какое отношение ?)
Возможно я не правильно применил пользователь, тогда уточню мысль. Имеется в виду последовательное выполнение команд, отсюда и линейное программирование. Например.
<b>begin</b>
Connect;
<b>try</b>
 get ...
<b>try</b>
 Close';
<b>end</b>;
Вместо
<b>procedure</b> x.Load;
<b>begin</b>
 Connect;
<b>end</b>;

<b>procedure</b> x.OnConnect;
<b>begin</b>
 Get;
<b>end</b>;

<b>procedure</b> x.OnCompete;
<b>begin</b>
 ...;
<b>end</b>;

<b>procedure</b> x.OnError;
<b>begin</b>
 ...;
<b>end</b>;

<b>procedure</b> x.Прочие обработчики;
<b>begin</b>
 ...;
<b>end</b>;
Сравни с компонентами Дельфи и сравни со чтением файлов. Вот для случая загрузки файла, что является линейным процессом первый метод явно проще, но не дает гибкости. А если логика сложная, то придется писать многостраничные строки кода с анализом состояний и реализовывать State машину. Очень напоминает Си с его многостраничными case в процедуре обработки сообщений Виндоус и сравни тоже самое с обработчиками Message.Вот у Инди именно этот подход.В более современных сложных компонентах они как то это попытались реализовать внутри, скрыв логику, но получилось это не в стили Дельфи и криво. Поэтому у меня сложилось мнение об применимости только для простейших случаев линейного процесса, а не для нелинейного, иначе потребуется потратить очень много усилий и результат будет далек от нужного.Не все же монстры ака apache или oracle - это монстры с большим опытом и большой командой, а Инди по сути написан одним человек с привлечением еще одного помощника и создавался он под Юникс, а на Виндоус портирован с той же самой идеологией.Я переводил их книгой и проникся их идеологией, так чтобы сказать - нам этого не надо, вот если писать в Кайликсе, тогда возможно не будет другого выбора, да и идеология их, а не наша.
а) никто не заставляет их использовать - всегда можно безжалостно выбросить
Так не выходит, поскольку речь об бесплатных альтернативах, с платными не каждому по пути. Кроме того мой путь использовать компоненты из поставки, если только нет другого выхода.
б) но начинающие - то про это не знают ;) Вот и попадаются каждый раз на бесплатный сыр. А с другой стороны - это не баг, а фича - не было бы сторонних компонент - было бы скучно ;)
Вот именно, что начинающие не могут сделать правильного решения, как правило, а есть ли компонент для расчета A+BМогу сказать, что мне не скучно, поскольку это особый проект, то я привлек только два посторонних компонента - это ICS (знаю давно и выбор не случаен, но если бы устроил Инди, то не стал бы использовать) и Absolute Database, коммерческая версия, поскольку нужна полностью эмбедед база, в том числе работающая с СД и даже без файла базы данных. По сути еще нужен TNT, но в данном проекте решил не делать Юникод приложение, но возможно еще передумаю.И это все, что у меня есть из посторонних компонент и то, только для данного проекта, а так используется только один.Проблему с Юникод генераторами отчетов решил за счет Экселя, работает стабильно и быстро, хотя по слухам многим это не удается, думаю не поняли идеологию DOM от Микрософта и основы СОМ (судя по вопросам в форумах и примерах, народ в основном остался на OLE - я же сразу поставил цель СОМ, потрахался правда два дня пока не проникся).


JohnS

Сравни с компонентами Дельфи и сравни со чтением файлов. Вот для случая загрузки файла, что является линейным процессом первый метод явно проще, но не дает гибкости. А если логика сложная, то придется писать многостраничные строки кода с анализом состояний и реализовывать State машину. Очень напоминает Си с его многостраничными case в процедуре обработки сообщений Виндоус и сравни тоже самое с обработчиками Message.Вот у Инди именно этот подход.
Вот именно. Вопрос лишь - в базовой идеалогии. Но опять же, где хороша модель обработчиков событий, а где она плоха. Сетевой обмен - это, по сути, достаточно регламентированный (в пределах групп операций) последовательный процесс, и концепция обработчиков событий - не всегда и удобна (в попытках отслеживать именно линейность процесса).Кроме того - попросту избыточна - потому как бессмысленная надстройка над надстройкой и только ради того, чтобы выдержать "стиль Delphi". Опять же, можно рассмотреть последовательность команд получения ftp файла, отправки email сообщений и пр. А на практике - истина, похоже, где-то посредине, т.е. нужно и правильно разрисовать и машину состояний/событий (Activity/State) и последовательность линейных операций (Sequence diagram).Но в любом случае, сама идея indy - она довольно тупиковая, в своей попытке привязать ту парадигму, которая хорошо работает в предметной области RAD UI, но довольно плохо - в области сетевого взаимодействия.Впрочем, и это голословно, потому как проблема indy - скорее в отвратной базовой реализации (бардачности). Такое ощущение, что компоненты писались по принципу "галочки" - говоря проще - "щоб було".
Не все же монстры ака apache или oracle - это монстры с большим опытом и большой командой, а Инди по сути написан одним человек с привлечением еще одного помощника и создавался он под Юникс, а на Виндоус портирован с той же самой идеологией.
Вот вот. Потому лучше пользоваться проверенными стандартными решениями, чем самому бодаться с детскими идеалогическими болезнями.
Я переводил их книгой и проникся их идеологией, так чтобы сказать - нам этого не надо, вот если писать в Кайликсе, тогда возможно не будет другого выбора, да и идеология их, а не наша.
Кайликс - это отдельный и очень больной вопрос. И "маркетинга" и реализации. Хотя - очень жаль, что проект загнулся.
Кроме того мой путь использовать компоненты из поставки, если только нет другого выхода.
Тоже подход, многие практикуют, и весьма успешно. Проблема только в том, что базовые компоненты - нельзя "расширять" (да и править - довольно проблематично - сколько раз приходилось скрипеть зубами, при виде Set-теров строго в private)
Вот именно, что начинающие не могут сделать правильного решения, как правило, а есть ли компонент для расчета A+B
Да, но следует отметить, что возможности то у них - просто огромные. Google, torry, форумы, ньюсы. Сейчас найти информацию, в т.ч. и о практических аспектах - совсем просто. Было бы желание.
народ в основном остался на OLE - я же сразу поставил цель СОМ, потрахался правда два дня пока не проникся).
Да потому что примеры все на идут на OLE ("спасибо" VBA), а COM/DCOM интерфейсы/диспинтерфейсы/маршаллинг и пр. изучать - это нудно, долго и типа "нафик надо, и так все работает"


JohnS

Может я не совсем точно выразил свою мысль, но сокеты Виндоус (не считая редких случаев применения блокирующих сокетов), работают как раз по идеологии Дельфи. Делается запрос и программа может отдыхать и выполнять свои дела, когда придут данные или ответ, то происходит событие и сообщение посылается программе. Типичная идеология Дельфи. С блокирующими сокетами не так делается вызов и программа ждет возврата из функции. Поэтому эта идеология не работает без потоков и противоречит общей идеологии как Виндоус, так и Дельфи. Но это удобно для простого линейного алгоритма, не важно есть машина состояний или нет. А вот для множества клиентов и непредвиденных ответов она уже тяжела, плюс накладываются ограничения на количество потоков и чем их больше тем сложнее взаимодействие.ICS требует только одного слушающего сокета для любого количества клиентов и это не использует никаких потоков. При подсоединении клиента автоматически создается новый сокет (клиентское соединение) и вся работа ведется с ним без помех другим клиентам и без потоков. Каждое клиентское соединение имеет свою очередь выборки сообщений, точно также как и поведение других программ в Виндоус.Поэтому обработать скажем 100 000 клиентов не составляет сложности, по сути программа все время находится в состоянии ожидания. ICS существует с 2000 года или ранее и один и тот же код работает и для Д1 и для 2006, естественно с некоторыми ограничения от версии Дельфи и Виндоус.


JohnS

Господа программеры , мы отдалились от темы . Мне не надо делать многопоточное приложение на 5000 клиентов .Мне крайне интересно :1.Если на INDY FTP принимает нормально файлы у трехсот клиентов , но виснет у тристапервого , СТОИТ ли мне переходить на ICS ???????????????2. У кого нибудь была похожая проблема ? Решилась ли она переходом на ICS ?


JohnS

А вот еще непонятно , если ключевые компоненты написаны через анус , зачем тогда жить вобще ??


JohnS

Не жди добрых слов, хотя твой вопрос тривиальный.
Ну вот , никто меня не любит :-((((((((


JohnS

Для FTP get никакого смысла нет.Кроме того твоя проблема выеденного яйца не стоит, под силу даже самым начинающим, а уж моделирование и знаний программирования не требует, у нас любой пользователь в состоянии вытащить сетевой кабель.


JohnS

А вот еще непонятно , если ключевые компоненты написаны через анус , зачем тогда жить вобще ??
Не через анус, а только некоторые самые сложные и то не через анус, а просто сложно. Просто ИНДИ это чужеродный инструмент и для Дельфи и для Виндоус. Но мользоваться можно, тем более для такой тривиальной штуки как ФТП клиент.Дело не в Инди.


JohnS

ftp вполне нормально на Indy работает. без потоков правда :)


JohnS

<b>procedure</b> x.OnCompete;
Описочка по Фрейду?


JohnS

Описочка по Фрейду?
Куда без дедушки Фрейда.