|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Semenyaka 2:461/640.640 15 Jan 2007 21:47:18
To : Alexander Kolesnikoff
Subject : проблемы в связке squid + TSO + windows 98
--------------------------------------------------------------------------------
15 Jan 07 20:07, you wrote to me:
>> >> А что с ней не так? Специально не изучал, но в случаях, когда такое
>> >> наблюдалось - отправитель честно переставал передавать данные.
>> AK> Всё так, только вот если и дальше окно не открывать, сессия
>> AK> стоит мертвая.
>> Hу слава богу, так и должно быть. Я был бы неприятно удивлён, если бы
>> я закрыл окно, а отправитель продолжал мне что-то передавать.
>> AK> В отличии от фряхи, у виндюка таймауты гораздо меньше и сессию
>> AK> она завершает раньше (в моём случае это был телнет). Кстати, не
>> AK> помню
>> AK> сейчас, отвалился ли сам вообще в этом тесте телнет на фряхе.
>> Если фришка ничего не пыталась послать - то и не должен был
>> отвалиться. А по каким признакам он это может сделать, пардон?
AK> Приложение, разумеется, должно оборвать сессию по таймауту. А ядру -
AK> пофигу. Оно может и до "страшного суда" держать такую сессию. ;-)
Приложение? Оно тоже вовсе не должно ничего обрывать по таймауту. С какого
перепугу? Чтобы сделать persistent connection невозможными и жизнь испортить,
или зачем? :)
Кстати, если приложение сессию порвало, то ядро этого хоста должно эту сессию
прибить.
>> Он должен отвалиться либо если keepalive не прошёл (а был включён ли?
>> да и таймауты на нём немалые), не смогли в после многих попыток пакет
>> послать или с той стороны RST пришёл. В противном случае (ничего не
>> отсылаем и ждём) - он и будет висеть, потому что kern_telepat.c не
>> написан :)
AK> И не надо ничего дописывать лишнего. Здесь нет неопределённости. ;-)
Hу да. Только непонятно, что тебе не нравится. Всё работает правильно, ровно
как должно :)
>> >> Подождём от Дениса результата двух экспериментов, которые я
>> >> описал...
>> AK> В связи с вновь открывшимися обстоятельствами (pf) всё ясно.
>> AK> Только
>> Я ещё не видел этих обстоятельств :) Hе дошло, видимо, пока письмо.
Уже увидел. И чем synproxy кому мешает?
>> AK> ... Понятно, что это сделано было не специально. Полагаю, надо эту
>> AK> фичу выключить. Может и проблема с клиентами win98 решиться.
>> Hет, может быть, конечно. Hо это какое-то гадание на кофейной гуще...
>> Из серии "у меня было ещё много интересных идей".
AK> И всё-таки ты сам же и соглашаешься, что "может быть". ;-)
К сожалению, я много чего видел в жизни. Hо пробовать идеи из серии "а вдруг" я
привык только после того, как все другие пути решения абсолютно исчерпаны. А
тут ещё изучать и изучать проблему, и, скорее всего, можно разобраться, что
именно не срабатывает и почему. Что намного лучше, чем получить результат
шаманством - потому что от шаманства ни опыта никакого не получаешь, ни
воспроизводимости никакой не гарантируется...
AK> Hу да, это танцы с бубном. А какие ещё могут быть рекомендации
AK> здесь? Человек же не зря сказал, что заставить всех клиентов
AK> поменять опер - лучше застрелится. Значит на своей стороне надо
AK> что-то делать. Остаюсь при своём мнении: этот sys-proxy - абсолютно
AK> лишняя фича в данной ситуации.
AK> (*)
Было предложено зайти на машину клиента удалённо - после чего там поставить
ethereal и снять сессию с той стороны. Возможно, там будет что-то яснее.
Кроме того, я бы ещё проверил, что с промежуточными MTU - есть ли проблема?
Если есть, то начиная с какого размера пакета она начинается?
После этого уже бы анализировал информацию и думал, что делать дальше.
Можно, конечно, превентивно отключить synproxy и посмотреть на результат. Hо,
думаю, ничего не поменяется. Hе мешает же synproxy, когда MTU большой.
Alex
--- IMHO в последней инстанции
* Origin: ...можжевеловых... (2:461/640.640)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
