История изменений
Исправление www_linux_org_ru, (текущая версия) :
Мде. Какому демону?
ну мы че, в детском саду что ли? проблема: «не делать повторяющихся arp-запросов»; очевидное решение: «сделать юзерспейсного демона, который будет этим заниматься»; решение торвальдса: «поместить arp resolution в ядро!111»
Ладно, думай еще.
я подумаю в любом случае
я пока что вижу единственную проблему: ядерные реализации, хотя и страдают от взлома, потенциально могут предоставлять большую консистентность данных, чем сделанные на коленке libvasypupkintcpip.so (т.к. данные будут констентны по построению)
но проблема эта решается тем, что ядро будет валидировать то что важно, а то, что не очень важно (типа как случай когда libvasypupkintcpip.so по ошибке послала пакет, предназначавшийся для 192.168.0.1 mac AABBCCDDEE11 по адресу 192.168.0.1 mac AABBCCDDEE22, где последний мак адрес — это адрес 192.168.0.2) окупается повышением устойчивости в случае взлома
з.ы. могут быть, кстати, и другие, более интересные решения
Исправление www_linux_org_ru, :
Мде. Какому демону?
ну мы че, в детском саду что ли? проблема: «не делать повторяющихся arp-запросов»; очевидное решение: «сделать юзерспейсного демона, который будет этим заниматься»; решение торвальдса: «поместить arp resolution в ядро!111»
Ладно, думай еще.
я подумаю в любом случае
я пока что вижу единственную проблему: ядерные реализации, хотя и страдают от взлома, потенциально могут предоставлять большую консистентность данных, чем сделанные на коленке libvasypupkintcpip.so (т.к. данные будут констентны по построению)
но проблема эта решается тем, что ядро будет валидировать то что важно, а то, что не очень важно (типа как случай когда libvasypupkintcpip.so по ошибке послала пакет, предназначавшийся для 192.168.0.1 mac AABBCCDDEE11 по адресу 192.0.0.1 mac AABBCCDDEE22, где последний мак адрес — это адрес 192.168.0.2) окупается повышением устойчивости в случае взлома
з.ы. могут быть, кстати, и другие, более интересные решения
Исправление www_linux_org_ru, :
Мде. Какому демону?
ну мы че, в детском саду что ли? проблема: «не делать повторяющихся arp-запросов»; очевидное решение: «сделать юзерспейсного демона, который будет этим заниматься»; решение торвальдса: «поместить arp resolution в ядро!111»
Ладно, думай еще.
я подумаю в любом случае
я пока что вижу единственную проблему: ядерные реализации, хотя и страдают от взлома, потенциально могут предоставлять большую консистентность данных, чем сделанные на коленке libvasypupkintcpip.so (т.к. данные будут констентны по построению)
но проблема эта решается тем, что ядро будет валидировать то что важно, а то, что не очень важно (типа как случай когда libvasypupkintcpip.so по ошибке послала пакет, предназначавшийся для 192.0.0.1 mac AABBCCDDEE11 по адресу 192.0.0.1 mac AABBCCDDEE22, где последний мак адрес — это адрес 192.0.0.2) окупается повышением устойчивости в случае взлома
з.ы. могут быть, кстати, и другие, более интересные решения
Исходная версия www_linux_org_ru, :
Мде. Какому демону?
ну мы че, в детском саду что ли? проблема: «не делать повторяющихся arp-запросов»; очевидное решение: «сделать юзерспейсного демона, который будет этим заниматься»; решение торвальдса: «поместить arp resolution в ядро!111»
Ладно, думай еще.
я подумаю в любом случае
я пока что вижу единственную проблему: ядерные реализации, хотя и страдают от взлома, потенциально могут предоставлять большую консистентность данных, чем сделанные на коленке libvasypupkintcpip.so (т.к. данные будут констентны по построению)
но проблема эта решается тем, что ядро будет валидировать то что важно, а то, что не очень важно (типа как случай когда libvasypupkintcpip.so по ошибке послала пакет, предназначавшийся для 192.0.0.1 mac AABBCCDDEE11 по адресу 192.0.0.1 mac AABBCCDDEE22, где последний мак адрес — это адрес 192.0.0.2) окупается повышением устойчивости в случае взлома