Я использую 64-разрядную версию Windows 7 Professional. Два разных клиента SSH демонстрируют странную привычку периодически зависать или зависать. Я пробовал как putty, так и SSH-клиенты Van Dyke SecureCRT, и в обоих случаях я получаю периодическое зависание, которое длится от 20 секунд до нескольких минут. Во время зависания не происходит нажатия клавиш (ни Ctrl-C, Ctrl-Z или что-то еще, что я пробовал).
Это происходит при подключении к любому из нескольких серверов. У других в моей группе, использующих машины, отличные от Windows, эта проблема не возникает. Так что, вероятно, это проблема не на стороне сервера.
Я также использую RDP для подключения к серверам Windows без подобных зависаний, поэтому не думаю, что это проблема с сетью на моем компьютере.
Поскольку это происходит с двумя разными клиентами, похоже, что это проблема Windows.
Какие-либо предложения?
ОБНОВИТЬ. Уделяя немного больше внимания, это, кажется, происходит только тогда, когда я использую emacs на удаленном сервере. Поскольку замораживание началось только при переходе с Windows XP на Windows 7, я отнес его к Windows, но, возможно, это связано с более тонким взаимодействием между emacs и Windows 7.
ДАЛЬНЕЙШЕЕ ОБНОВЛЕНИЕ. Мой специалист по поддержке рабочего стола заменил сетевой кабель, и проблема, похоже, исчезла. Я не могу объяснить, почему я не заметил проблем с сетью на моем компьютере, кроме как при работе с Emacs через ssh. Возможно, в использовании Emacs таким образом есть что-то особенно чувствительное к нестабильности сети.
Я использую шпатлевку под окна и не имею этой проблемы. В окнах нет ничего внутреннего, что могло бы вызвать эту проблему. Это может быть что-то вроде антивирусного брандмауэра Symantec или другого программного обеспечения, которое прерывает соединение.
Описанная проблема тоже очень раздражала. Я пробовал подход с отключением разгрузки большой отправки и Jumbo Packet, как было предложено выше (а также другие параметры в свойствах сетевого адаптера> вкладка «Дополнительно»). К сожалению, положительный результат был лишь «кратковременным»: после перезагрузки адаптера, необходимой для активации выбранных параметров адаптера, все было нормально, но затем через некоторое время (несколько минут) сессия ssh стала тормозной / зависала.
Наблюдаемое поведение («плавный» SSH сразу после перезагрузки адаптера и запаздывание через некоторое время) подсказывало взглянуть на параметры энергосбережения. Наконец, проблема была решена отключением параметра «Разрешить компьютеру выключать это устройство для экономии энергии» в Диспетчере устройств> Сетевые адаптеры> Свойства адаптера> Управление питанием. Проблема / решение были успешно воспроизведены после включения / выключения этой опции (результат виден через несколько минут без перезагрузки адаптера).
Подход был протестирован на следующих настройках программного обеспечения: SSH Secure shell в Windows 7 Professional 64-bit и Putty в Windows 7 Ultimate 64-bit, оба подключены к разным серверам Linux.
Вообще говоря, для связи Windows 7/2008 через VPN или какую-либо глобальную сеть я бы рекомендовал отключить свойства сетевого адаптера> вкладка «Дополнительно»> «Большая отправка, разгрузка» и «Большой пакет».
Я думаю, что это как-то связано с брандмауэром, прерывающим соединение. Некоторое время назад я испытал аналогичную проблему, но со всеми клиентскими операционными системами. Через некоторое время ssh-соединения были прерваны. После отладки мы обнаружили, что тайм-аут простоя был настроен на очень низкий предел в брандмауэре между клиентскими машинами и этим сервером.
Поскольку эта проблема возникает только в Windows 7, я предполагаю, что это может быть программный брандмауэр, установленный на клиентских машинах.
Надеюсь это поможет!
У меня были проблемы с использованием vi в Putty + Windows 7. Как только я пытаюсь открыть файл на удаленном сервере с помощью vi, Putty зависает. Затем мне пришлось убить Putty и начать новую.
Мое исправление состояло в том, чтобы отключить пересылку X11 на Putty. Надеюсь это поможет.
Вы запускаете параллельно какое-либо программное обеспечение, которое перехватывает / контролирует клавиатуру? Может быть, какое-нибудь анти-RSI программное обеспечение или менеджер горячих клавиш / макросов? (Не забудьте менеджеры горячих клавиш для дополнительных кнопок на мультимедийной клавиатуре или клавиатуре ноутбука.)
Такое программное обеспечение может запутаться из-за сочетаний клавиш управления и Esc, которые часто используются самим eMacs и / или самой эмуляцией терминала.
У меня были похожие проблемы в XP и Win7, вызванные анти-RSI программным обеспечением наших компаний. Затронутые telnet и ssh, независимо от используемого программного обеспечения: собственный telnet Windows, клиент cygwin ssh и xterm, putty, SecureCrt, Reflection-X, Attachmate-Extra, eXceed. У всех были проблемы. Я избавился от программного обеспечения против RSI, и проблемы также исчезли. Теперь я использую WorkRave, который, похоже, не влияет на работу терминальных сессий.