ArtLonger "inbound connect" - входящие соединение
"outbound connect" - исходящие соединение
"inbound disconnect" - дисконнект инициированный удалённым сервером
"outbound disconnect" - дисконнект инициированный локальной машиной
Цитата: PS: Вопрос. Если Jetico какой троян уронит, то файер за собой соединение рубит?
конфигурация останется прежней. т.е. ничего нового разрешено не будет, но и ничего, что было разрешено, запрещено не будет.
Добавлено kkk4 Цитата: Это Jetico не понимает, для (от) какого приложения эти муловские пакеты, или...?
Эо служебные пакеты низкого уровня, которые не несут в себе данных, а лишь говорят о подтверждении разъединения. На нижнем уровне у JPF нету привязки к приложению.
Цитата: Собственно, при добавлении мула в доверенные приложения ситуация та же. Сам мул нормально работает в обе стороны. Лог моментально разрастается до max. заданного размера, что подтормаживает работу системы, пока запретил его...
Я изучал этот вопрос. Дело в том, что JPF сильно честный. Проблеммы сдесь в M$ или eMule. При "вежливом" закрытии соединения посылается запрос на разъединение, и на него должно быть получено подтверждение. Но M$ часто грешит тем, что посылает запрос на дисконнект(FIN) и недожидаясь ответа(FIN ACK) посылает пакет об "аварийном" закрытие соединения(RST), который не требует подтверждения. Тем самым подтверждение от удалённого сервера приходит уже для закрытого соединения.
JPF отслеживает протокол, и естественно считает пакет с подтверждением лишним.