pipe in bash

[rojer]

Troll> это чисто локальная операция, с другой стороны tcp-соединения этого вообще не видно

насколько я понимаю, на shutdown посылается fin и соединение переходит в half-open режим. при этом передача в другую сторону возможна ещё сколь угодно долго, но при попытке чтения другая сторона будет получать 0. вопрос, не смущает ли это сквид?

Troll> убунта 8.10 с последними апдейтами

ну вот, редхат перешёл на новый опенбсдшный, а дебиан и, как следствие, убунта - нет. в том и разница, стало быть.

upd: подампал - так и есть. вот смесь вывод tcpdump и strace:

read(0, "GET cache_object://127.0.0.1/inf"..., 1024) = 47
write(3, "GET cache_object://127.0.0.1/inf"..., 4723:30:36.083853 IP 10.0.0.1.57253 > 10.0.0.2.8079: P 1:48(47) ack 1 win 46 <nop,nop,timestamp 3394157776 85347431>
0x0000: 4500 0063 c188 4000 4006 6adf 596f aabc E..c..@.@.j.Yo..
0x0010: 0a00 0002 dfa5 1f8f 2ea0 7d4a 35d1 da69 ..........}J5..i
0x0020: 8018 002e 0e83 0000 0101 080a ca4e bcd0 .............N..
0x0030: 0516 4c67 4745 5420 6361 6368 655f 6f62 ..LgGET.cache_ob
0x0040: 6a65 6374 3a2f 2f31 3237 2e30 2e30 2e31 ject://127.0.0.1
0x0050: 2f69 6e66 6f20 4854 5450 2f31 2e30 0d0a /info.HTTP/1.0..
0x0060: 0d0a 0a ...
) = 47
poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN, revents=POLLHUP}], 2, -1) = 1
shutdown(3, 1 /* send */23:30:36.084091 IP 10.0.0.1.57253 > 10.0.0.2.8079: F 48:48(0) ack 1 win 46 <nop,nop,timestamp 3394157776 85347431>
0x0000: 4500 0034 c189 4000 4006 6b0d 596f aabc E..4..@.@.k.Yo..
0x0010: 0a00 0002 dfa5 1f8f 2ea0 7d79 35d1 da69 ..........}y5..i
0x0020: 8011 002e d43a 0000 0101 080a ca4e bcd0 .....:.......N..
0x0030: 0516 4c67 ..Lg
) = 0

обрати внимание на FIN после shutdown(3, SHUT_WR). после этого назад приходит нормальный ответ, потом FIN и последний от нас ACK.
правда, на lo у меня этого не происходит - там большой MTU и весь ответ сервера помещается в первый же пакет, за которым сразу следует FIN. но теория такова

upd2: если опустить mtu на lo до 1500, то этот fin разглядеть удётся. в общем, маловероятно, но всё же. хочется увидеть алексов tcpdump, что конкретно у него происходит.

[AlexM]

Сообщение от rojer

rpm -q --whatprovides /usr/bin/nc

nc-1.84-13.fc8


tcpdump (выбросил первые три, которые соединение устанавливают):

[root@v]# /usr/sbin/tcpdump -n -i lo -X -s 16384 port 4
04:48:39.584870 IP 127.0.0.1.4 > 127.0.0.1.us-srv: P 1:48(47) ack 1 win 257
        0x0000:  4500 0057 ace6 4000 4006 8fb8 7f00 0001  E..W..@.@.......
        0x0010:  7f00 0001 0004 1f93 2283 39c0 21db e990  ........".9.!...
        0x0020:  5018 0101 fe4b 0000 4745 5420 6361 6368  P....K..GET.cach
        0x0030:  655f 6f62 6a65 6374 3a2f 2f31 3237 2e30  e_object://127.0
        0x0040:  2e30 2e31 2f69 6e66 6f20 4854 5450 2f31  .0.1/info.HTTP/1
        0x0050:  2e30 0d0a 0d0a 0a                        .0.....
04:48:39.584870 IP 127.0.0.1.us-srv > 127.0.0.1.4: . ack 48 win 257
        0x0000:  4500 0028 7ccb 4000 4006 c002 7f00 0001  E..(|.@.@.......
        0x0010:  7f00 0001 1f93 0004 21db e990 2283 39ef  ........!...".9.
        0x0020:  5010 0101 295c 0000                      P...)\..
04:48:39.584870 IP 127.0.0.1.4 > 127.0.0.1.us-srv: F 48:48(0) ack 1 win 257
        0x0000:  4500 0028 ace7 4000 4006 8fe6 7f00 0001  E..(..@.@.......
        0x0010:  7f00 0001 0004 1f93 2283 39ef 21db e990  ........".9.!...
        0x0020:  5011 0101 295b 0000                      P...)[..
04:48:39.601868 IP 127.0.0.1.us-srv > 127.0.0.1.4: F 1:1(0) ack 49 win 257
        0x0000:  4500 0028 7ccc 4000 4006 c001 7f00 0001  E..(|.@.@.......
        0x0010:  7f00 0001 1f93 0004 21db e990 2283 39f0  ........!...".9.
        0x0020:  5011 0101 295a 0000                      P...)Z..
04:48:39.601868 IP 127.0.0.1.4 > 127.0.0.1.us-srv: . ack 2 win 257
        0x0000:  4500 0028 ace8 4000 4006 8fe5 7f00 0001  E..(..@.@.......
        0x0010:  7f00 0001 0004 1f93 2283 39f0 21db e991  ........".9.!...
        0x0020:  5010 0101 295a 0000                      P...)Z..

какая-то странная десяточка в конце запроса присутствует, но сквид вроде на это дело плюет, по-крайней мере в логах молчек.
фактически дамп показывает что nc инициирует закрытие конекта и, похоже, даже не пытаясь читать (ну, судя по таймштамп). чегой-то он?
кстати, если я указываю ET вместо GET то от сквида ответ получаю, ругательный ессно.

[rojer]

AlexM> nc-1.84-13.fc8

достаточно современный.

что касается дампа - ну, что и требовалось доказать, в общем. по сети ничего не идёт.
относительно того, почему - вроде бы тоже оправдывается подозрение сквида на неадекватную обработку полузакрытых коннектов. если nc успевает коннект закрыть и послать fin до того как сквид его обработал (а это зависит от того, когда случатся переключения контекста), то сквид не отвечает.
у меня на федоре 9 это почти повторилось, хотя и не совсем - мне он таки отплёвывает заголовок ответа, но без тела.
опыт был поставлен такой: сквида замораживаем (killall -STOP squid), делаем echo | nc, разморажиаем и получаем в ответ заголовок без тела. тот же опыт с телнетом - замораживаем сквид, телнетимся, вбиваем запрос, размораживаем - ответ получаем полный. а разница только в том, полчил сквид fin во время заморозки или нет.

такие дела...
не знаю даже что посоветовать. собрать специальный nc без shutdown? правильно, наверное, конечно, починить сквида...

rojer добавил 07.04.2009 в 18:39
AlexM> какая-то странная десяточка в конце запроса присутствует

это от эха, надо echo -n. но это фигня.

AlexM> фактически дамп показывает что nc инициирует закрытие конекта и, похоже, даже не пытаясь читать

не так. он закрывает свою сторону соединения - типа, у нас всё. коннект переходит в half-open состояние, в котором может находиться сколько угодно.
а у сквида, похоже, крышу сносит, хотя не должно - запрос-то был ему даден, надо отрабатывать и отвечать, а он дропает конект. в твоём случае сразу, в моём - после отдачи заголовков.

AlexM> кстати, если я указываю ET вместо GET то от сквида ответ получаю, ругательный ессно.

это, скореевсего, из-за разных путей по которым идёт нормальный и ошибочный запрос.


короче, nc имхо формально прав. но, скажем так, шибко умно себя ведёт.

[AlexM]

Сообщение от rojer

не так. он закрывает свою сторону соединения - типа, у нас всё. коннект переходит в half-open состояние, в котором может находиться сколько угодно.

ты прав, я сказал сквиду чтобы он воспринимал половинные конекты и все заработало.
однако nc хоть формально и прав, все-таки не прав, бо получается ни к какому явовскому серверу к примеру он прицепиться не может, бо ява не понимает полу-коннекты . фактически ключик бы надо иметь nc, что ли. хотя конечно он наверное шлет ФИН потому что видит, что на вход ему больше ничего не дадут. в общем, недоработочка какая-то чувствуется.

[rojer]

AlexM> сказал сквиду чтобы он воспринимал половинные конекты и все заработало.

оп-па, "а мужики-то не знают" (c)
что за опция такая?

AlexM> однако nc хоть формально и прав

нет, как ни крути, а nc прав даже с точки зрения здравого смысла, ибо таким образом сигнализирует EOF у себя на входе. не будет EOF - не будет закрытия.

[AlexM]

Сообщение от rojer

оп-па, "а мужики-то не знают" (c)
что за опция такая?

half_closed_client on/off

Сообщение от rojer

нет, как ни крути, а nc прав даже с точки зрения здравого смысла, ибо таким образом сигнализирует EOF у себя на входе. не будет EOF - не будет закрытия.

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