Здравствуйте, Шебеко Евгений, Вы писали:
ШЕ>Вычитывать данные без необходимости, только ради того чтобы их вычитать — это зло. ШЕ>Я это прочувствовал на собственных программах. Де факто процессы клиента и сервера работают с разной скоростью. ШЕ>И как только клиентов становится много, а сервер нагруженным, данные с клиента начинают обрабатываться (например записываться в базу) ШЕ>медленнее, чем поступают с клиентов. И ваша буферизация приведёт к тому, что сервер просто упадёт. Если вы ограничите размер буфера, ШЕ>добьётесь только того, что потратите память (т.к. сервер нагружен постоянно, то и данные поступают постоянно).
В данном случае, если клиенту необходимо передать серверу большой объем данных, рекомендуется организовать логическую синхронизацию на прикладном уровне, так как сеть — это не "бездонная труба", и если туда кидать все данные сразу — есть большая вероятность в падении скорости из-за перегрузки трафика повторными пакетами. Т.е. по уму — клиент должен узнать у сервера, какой объем тот готов принять, а не пересылать все что у него есть. Почитай например Jon C. Snader, Effective TCP/IP Programming (Эффективное программирование TCP/IP) — там в последних главах обсуждается вопросы эффективного использования сети и проблема размера буферов.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Serj_K, Вы писали:
N>Простите, что значит "забивая сетевой трафик" в данном случае? Как Вы это себе представляете? Неужели то, что передаваемые данные будут накапливаться и застревать в маршрутизаторах?)
N>....
Ответ здесь
S_K>В данном случае, если клиенту необходимо передать серверу большой объем данных, рекомендуется организовать логическую синхронизацию на прикладном уровне,
Так то оно так, но это вовсе не означает, что надо изгаляться и стремиться вычитать все данные, которые ты ещё не в состоянии обработать,
даже ещё не знаешь надо ли их вообще обрабатывать.
Клиентов тоже много может быть и небольшими пакетами от всех клиентов можно создать большой объём на сервере.
S_K>так как сеть — это не "бездонная труба", и если туда кидать все данные сразу — есть большая вероятность в падении скорости из-за перегрузки трафика повторными пакетами.
Подозреваю что HTTP при скачивании больших файлов так и делает. И ничего фильмы у вас не пропадают и браузер память не выжирает
пока вы решаете, куда сохранить файл или просто пишите на медленную флешку.
S_K>Т.е. по уму — клиент должен узнать у сервера, какой объем тот готов принять, а не пересылать все что у него есть.
Да не будет это работать лучше, чем работает сам TCP стек.
C1->S: А сколько я могу записать?
C2->S: А сколько я могу записать?
S->C1: 10000
S->C2: 10000
C1->S: На тебе 10000
C2->S: На тебе 10000
S: Bad alloc
S_K>Почитай например Jon C. Snader, Effective TCP/IP Programming (Эффективное программирование TCP/IP) — там в последних главах обсуждается вопросы эффективного использования сети и проблема размера буферов. S_K>P.S. Книгу можно достать в инете например тут: http://www.internet-technologies.ru/books/book_103.html
404 (
Обложка знакомая, но что-то не могу у себя сейчас найти.
Здравствуйте, Serj_K, Вы писали:
S_K>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, Serj_K, Вы писали:
N>>Простите, что значит "забивая сетевой трафик" в данном случае? Как Вы это себе представляете? Неужели то, что передаваемые данные будут накапливаться и застревать в маршрутизаторах?;))
N>>.... S_K>Ответ здесь
Это не ответ, извините за откровенность. Это больше похоже на невнятное лопотание, ещё и со ссылкой на недоступные источники (Вы сами-то ссылки пробовали? они мертвы).
Я повторяю вопрос более детально. Есть протокол, в котором допускается, что клиент передаёт запросы потоком не дожидаясь ответа сервера на предыдущие запросы. Есть клиент, который передаёт таким образом и для которого заполненный до предела выходной буфер — нормальная ситуация. Что именно в данной организации неэффективно? И, чтобы не говорить голословно — ситуацию рассмотрим на примере RFC4644 и его конкретной реализации в виде innfeed. Прошу рассказать, как именно innfeed забивает сетевой трафик и кому он при этом мешает.
Здравствуйте, Шебеко Евгений, Вы писали:
ШЕ>Подозреваю что HTTP при скачивании больших файлов так и делает. И ничего фильмы у вас не пропадают и браузер память не выжирает ШЕ>пока вы решаете, куда сохранить файл или просто пишите на медленную флешку.
Подозреваю, что браузер качает файл в кэш, пока вы решаете куда сохранит файл
(для IE есть такой каталог как C:\Documents and Settings\...\Local Settings\Temporary Internet Files\Content.IE5)
ШЕ>Да не будет это работать лучше, чем работает сам TCP стек. ШЕ>
C1->>S: А сколько я могу записать?
C2->>S: А сколько я могу записать?
S->>C1: 10000
S->>C2: 10000
C1->>S: На тебе 10000
C2->>S: На тебе 10000
ШЕ>S: Bad alloc
ШЕ>
Строка C2->>S: явно лишняя... Если TCP гарантирует доставку, не вижу необходимость посылать повторный запрос...
Здравствуйте, Serj_K, Вы писали:
S_K>Здравствуйте, Шебеко Евгений, Вы писали:
ШЕ>>Подозреваю что HTTP при скачивании больших файлов так и делает. И ничего фильмы у вас не пропадают и браузер память не выжирает ШЕ>>пока вы решаете, куда сохранить файл или просто пишите на медленную флешку. S_K>Подозреваю, что браузер качает файл в кэш, пока вы решаете куда сохранит файл ;) S_K>(для IE есть такой каталог как C:\Documents and Settings\...\Local Settings\Temporary Internet Files\Content.IE5)
ШЕ>>Да не будет это работать лучше, чем работает сам TCP стек. ШЕ>>
C1->>>S: А сколько я могу записать?
C2->>>S: А сколько я могу записать?
S->>>C1: 10000
S->>>C2: 10000
C1->>>S: На тебе 10000
C2->>>S: На тебе 10000
ШЕ>>S: Bad alloc
ШЕ>>
S_K>Строка C2->>S: явно лишняя... Если TCP гарантирует доставку, не вижу необходимость посылать повторный запрос...
Вообще-то C1 и C2 — разные клиенты одного сервера. С чего это Вы решили, что это будет "повторный запрос"?
Здравствуйте, Шебеко Евгений, Вы писали:
C1->>S: А сколько я могу записать? C2->>S: А сколько я могу записать? S->>C1: 10000 S->>C2: 10000 C1->>S: На тебе 10000 C2->>S: На тебе 10000 ШЕ>S: Bad alloc ШЕ>[/code]
Сорри, я не разобрал семантики...
В таком, случае строка S->>C2: 10000 лишняя. Т.е. если сервер предоставил 1-у клиенту память — то следует залочить эту память во избежание вышеописанной ситуации. Это мое мнение.
Здравствуйте, netch80, Вы писали:
N>Это не ответ, извините за откровенность. Это больше похоже на невнятное лопотание, ещё и со ссылкой на недоступные источники (Вы сами-то ссылки пробовали? они мертвы).
Пробовал — работает. Там между прочим есть название книги, если что. Было-бы желание — найти ее в инете не составит труда...
N>Я повторяю вопрос более детально. Есть протокол, в котором допускается, что клиент передаёт запросы потоком не дожидаясь ответа сервера на предыдущие запросы. Есть клиент, который передаёт таким образом и для которого заполненный до предела выходной буфер — нормальная ситуация. Что именно в данной организации неэффективно? И, чтобы не говорить голословно — ситуацию рассмотрим на примере RFC4644 и его конкретной реализации в виде innfeed. Прошу рассказать, как именно innfeed забивает сетевой трафик и кому он при этом мешает.
Извини — я не знаю что за innfeed и как он работает, так что ничего не смогу тебе ответить...
Здравствуйте, Serj_K, Вы писали:
N>>Это не ответ, извините за откровенность. Это больше похоже на невнятное лопотание, ещё и со ссылкой на недоступные источники (Вы сами-то ссылки пробовали? они мертвы). S_K>Пробовал — работает. Там между прочим есть название книги, если что. Было-бы желание — найти ее в инете не составит труда...
Я пока не понял, зачем мне стараться её искать.
N>>Я повторяю вопрос более детально. Есть протокол, в котором допускается, что клиент передаёт запросы потоком не дожидаясь ответа сервера на предыдущие запросы. Есть клиент, который передаёт таким образом и для которого заполненный до предела выходной буфер — нормальная ситуация. Что именно в данной организации неэффективно? И, чтобы не говорить голословно — ситуацию рассмотрим на примере RFC4644 и его конкретной реализации в виде innfeed. Прошу рассказать, как именно innfeed забивает сетевой трафик и кому он при этом мешает. S_K>Извини — я не знаю что за innfeed и как он работает, так что ничего не смогу тебе ответить...
Информацию об этом найти значительно проще, чем книгу. А прочитать RFC на десяток страниц — тем более. Так что ничего кроме "слив защитан" тут, увы, сказать не получается. Хорошо начинаете жизнь в форуме, коллега. Так держать.
Здравствуйте, netch80, Вы писали:
N>Я повторяю вопрос более детально. Есть протокол, в котором допускается, что клиент передаёт запросы потоком не дожидаясь ответа сервера на предыдущие запросы. Есть клиент, который передаёт таким образом и для которого заполненный до предела выходной буфер — нормальная ситуация. Что именно в данной организации неэффективно? И, чтобы не говорить голословно — ситуацию рассмотрим на примере RFC4644 и его конкретной реализации в виде innfeed. Прошу рассказать, как именно innfeed забивает сетевой трафик и кому он при этом мешает.
N>Информацию об этом найти значительно проще, чем книгу. А прочитать RFC на десяток страниц — тем более. Так что ничего кроме "слив защитан" тут, увы, сказать не получается. Хорошо начинаете жизнь в форуме, коллега. Так держать.
Хорошо, не будешь столь любезен выложить исходный код этого innfeed'а, а то мне, так-же как и тебе — лень искать книгу, лень копаться в документации. A я просмотрю его и расскажу свое мнение — забивает innfeed или нет сетевой трафик, как и почему...
А по описанному топикстартером примеру — давай разберемся сначала, перед тем как критиковать. Итак по моему разумению, при выключается алгоритм Нагла (который как раз и следит, чтоб мелкие пакеты не перегружали сеть) и при интенсивной отправке данных — TCP буфер сервера перегружается, так как он их не вычитывает. Пакеты после переполнения буфера на сервере остаются в сети и уничтожаются после завершения их времени жизни TTL. Поэтому, клиентская сторона отсылает их заново, и т.д. и т.д. Это разве не забивание трафика лишними пакетами, вместо того чтоб спокойно подождать, пока освободятся ресурсы сервера?
Если что-то не так — поправь меня.
Тем более логику алгоритма отправки данных можно построить таким образом, чтоб TCP буфер сервера не освобождался более чем, скажем на 50%, и тем самым исключить простаивание сервера, в ожидании следующего блока данных от клиента. А сеть в данном контексте является самым узким местом при передачи данных от клиента серверу — а следовательно самым дефицитным ресурсом. Поэтому его, по моему мнению, необходимо экономить в первую очередь.
Здравствуйте, Serj_K, Вы писали:
S_K>Хорошо, не будешь столь любезен выложить исходный код этого innfeed'а, а то мне, так-же как и тебе — лень искать книгу, лень копаться в документации. A я просмотрю его и расскажу свое мнение — забивает innfeed или нет сетевой трафик, как и почему... http://packages.debian.org/source/sid/innfeed
S_K>А по описанному топикстартером примеру — давай разберемся сначала, перед тем как критиковать. Итак по моему разумению, при выключается алгоритм Нагла (который как раз и следит, чтоб мелкие пакеты не перегружали сеть) и при интенсивной отправке данных — TCP буфер сервера перегружается, так как он их не вычитывает. Пакеты после переполнения буфера на сервере остаются в сети и уничтожаются после завершения их времени жизни TTL.
Бред. TTL — это максимальное количество хопов. После того, как пакет дошёл до назначения оно уже ни на что не влияет.
В общем, почитай что-нибудь по теории сетей, и устройству TCP/IP. Так как сплошной бред несёшь.
делать своё локальное зеркало не вижу смысла:)
S_K> а то мне, так-же как и тебе — лень искать книгу, лень копаться в документации. A я просмотрю его и расскажу свое мнение — забивает innfeed или нет сетевой трафик, как и почему...
ню ню:))
S_K>А по описанному топикстартером примеру — давай разберемся сначала, перед тем как критиковать. Итак по моему разумению, при выключается алгоритм Нагла (который как раз и следит, чтоб мелкие пакеты не перегружали сеть) и при интенсивной отправке данных — TCP буфер сервера перегружается, так как он их не вычитывает.
Нет.
S_K> Пакеты после переполнения буфера на сервере остаются в сети и уничтожаются после завершения их времени жизни TTL.
О боже. Пакеты остаются в сети. Это покруче славянских корней египтян.
S_K>Если что-то не так — поправь меня.
)
