Были протестированы разничные варианты связок сервера и клиента - везде все хорошо, кроме связки сервер на Windows и тестирующий клиент на Mac OS X. Эмпирическим путем, поскольку в связках Windows-сервер плюс Linux-клиент и Windows-сервер - FreeBSD-клиент все работает хорошо, было установлено, что проблема существует из-за того, что Mac OS X выделяет порты из динамического клиентского диапазона подряд (т.е. 49152, 49153 и т.п.), что приводит к тому, что Windows на некоторое время перестает обрабатывать коннекты (не реагирует на SYN-пакеты от клиента). При связках с другими OS, где порты клиентского диапазона выделяются не подряд, а в случайном порядке - Windows ведет себя нормально - его не смущает большой connection rate.
При этом, что интересно в Mac OS X по умолчанию клиентские порты были настроены на диапазон 49152-65535, при этом Windows подвисала где-то на 16000 обработанных соединениях. При установке диапазона на Mac OS X в 1025-65535 до коматоза было обслужено соответствующее число портов - около 64000.
Когда Windows перестает отвечать на запросы Mac, то если при этом коннектиться на этот же Windows-сервер с другой машины Linux или BSD - все ок. Но, если пробовать подключаться на этот же Windows-сервер, но уже с другого Mac, то он тоже не может коннектиться на эту винду. Таким образом Windows отвечает на запросы любых клиентов, кроме Mac - даже несмотня на то, что запросы идут с физически разных машин.
Если же с мака, когда он уже не может соединяться с виндой, попробовать законнектиться с сервером на любой другой машине под Linux/BSD - то все ОК. Но если с этого же Mac попробовать законнектиться на физически другой Windows-сервер, то коннект также не работает.
Думал, что по симптомам дело в свиче/рутере, но оказалось, что это не так - подключенные напрямую машины глючат также.
После достижения некоторого лимита на залоченный таким образом Windows-сервер не может подключить ни один Mac-клиент, а залоченный Mac-клиент не может подключиться ни к одному Windows-серверу.
Хотя к этому же Windows-серверу легко коннектстся клиенты других OS, также как и этот Mac-клиент легко коннектится к серверам на других OS.
Еще инетересно, когда подвисат ab, то запущенный телнет висит какое-то время, а потом оживает. Вероятно идет SYN ретрансмит, на который уже есть ответ от винды.
Что больше всего странно - что если это проблема винды, то почему залоченный Mac-клиент, не может законнектиться на физически другой Windows-сервер? А если это проблема Mac-клиента, то почему физически другой Mac-клиент не может законнектиться на залоченный Windows-сервер? Почему у обоих залоченных Windows-сервера и Mac-клиента сразу же после подвисона (или точнее выразиться в процессе) нет никаких проблем в коммуникации с другими OS (Linux/FreeBSD).
Да. Все машины, которые использовались в тесте - физические, не виртуальные. Так что это не проблема виртуализации.
P.S. Если кто поможет разобраться - ящик пива или, скажем, $100 - легко.
Еще инфа по теме с английского форума:
Questions answered so far:
1) is only ab connections hang? what about telnet?
telnet hangs either
2) is it sequental (not randomized) port usage on Mac OS X?
not likely. sequental port usage from other OS dosn't reproduce the problem - just from Macs. However increasing range of dymanic ports in Mac os makes for this Mac-client a possibility to process as many connections as there are ports before the hang out. But what about a connection to locked Windows-server from another physical Mac-client that also hangs (immediately)?
3) is it TIME_WAIT problem?
not likely. TIME_WAIT TCBs must be reused and Mac-client connection to another Windows-server both have no TIME_WAIT TCBs in netstat -na output. With Linux/BSD clients all is OK - so TIME_WAIT TCBs are properly reused.
4) is it port exhaustion problem?
not likely. as only a few connections open simultaneously. with 10 concurrent connections all the same sympthoms as with 100 or 1000. And locked Mac-client successfully connects to another server running other OS (Linux/BSD).
5) is tcpdump (or any other sniffer) shows difference in packet sessions/sequences in comparison to BSD/Linux clients?
no. not easily visible. all exactly the same sequence of packets. 3 packets for opening the connection (syn, syn+ack, ack) + 2 data packets (1 for each direction) + 4 packets for gracefully shutting down (lingering) the connection (fin and ack for each direction).
6) did you try NAT in between of server and client?
yes. but no positive results.
7) is it switch/router issue?
no. direct computer-to-computer connection did not help either
did you try different network settings?
yes. all that you can find on the internet for both OSes. none of them helped so far.
9) which systems are affected
tested with Vista, Server 2003, Server 2008, Mac OS X Tiger, Mac OS X Leopard - all latest patches applied.
a) is it virtualization issue?
no. each machine involved in the testing is a physically different piece of hardware.
b) is it a packet rate / network speed / latency problem?
1000, 100, 10, 2 Mbps show same problems. round trip time from <1 ms. up to 10 ms.
Так а где тогда дамп самого глюка? ну когда перестает соединять.
