И отваливается по таймауту. А если пускать как sudo то
18:20:42.716477 IP 192.168.0.188 > www.yandex.ru: ICMP echo request, id 10651, seq 8883, length 44
Так что получается, что все работает как и описано, только надо для java поставить suid, а этого обычно не делают и похоже делать не будут. Но я бы поменял на эту реализацию, потому что не надо нативы таскать с собой. И кстати пинги получаются нормальные
true 32 ms
true 29 ms
true 27 ms
true 27 ms
true 34 ms
true 27 ms
true 26 ms
true 24 ms
true 18 ms
А по поводу github. Я тоже везде где могу использую меркуриал, но хаб он богат community и если очень надо, то есть hg-git.
Да я вообще дистра не знаю, у которого нужен рут чтобы сделать ping.
А про реализацию надо почитать чуть-чуть внимательнее
A typical implementation will use ICMP ECHO REQUESTs if the privilege can be obtained, otherwise it will try to establish a TCP connection on port 7
Время его выполнения будет через System.currentMillis(). Не думаю что от тестовой утилиты требуется точность в наносекундах для определения пинга. Как по мне так нужно его наличие, порядок величин и количество потерь. А будет там 67 или 72 мс — не принципиально.
Sep 16, 2011 12:07:21 AM ru.krasu.edhel.jim.win.Worker onError
WARNING: Operation not permitted
java.io.IOException: Operation not permitted
at org.savarese.rocksaw.net.RawSocket.__throwIOException(RawSocket.java:183)
at org.savarese.rocksaw.net.RawSocket.open(RawSocket.java:263)
at ru.krasu.edhel.jim.util.Ping$Pinger.(Ping.java:93)
Ну я и не претендую, что я открыл какое-то сокровенное знание, которое никто не знает. И чем больше и больше я погружаюсь в akka тем больше мне начинает нравиться apache camel. Просто изучаю альтернативы и решил поделиться.
Во-первых авторы могут взаимодействовать между разными jvm — на одной машине надо просто импортировать актор с другой машины.
Про один поток на листенер это черевато вот чем — что будет когда у вас система будет работать с 1000 листнеров? Или с 10000? Так как акторы работают в пуле то для них это не имеет значения
Концепция акторов она как бы надпоточна, т.е. сообщения к одному актору должны обрабатываться последовательно и независимо. Поэтому по умолчанию создаются пулы процессов, которые обрабатывают сообщения. Есть возможность настроить akka так чтобы под какие-то акторы выделялся отдельный поток для обработки.
Акторы сами по себе могут быть stateful или stateless, это как вы захотите и как вам будет удобно. Создать новый актор это легкая операция и создавать их можно по мере необходимости из других акторов.
У самих акторов есть методы postStart preStop чтобы сохранять-восстанавливать состояние по необходимости.
А игры наиболее интересный с точки зрения пример, где любые другие подходы не тянут. Например, если у нас есть ферма, то для каждого объекта можно создать актор для обработки событий для него. Т.е. для каждого деревца, каждого кустика будет свой concurrent обработчик, который реагирует на действия разных игроков, и при этот система не умрет от огромного количества потоков.
Не совсем понял где я написал что ограничена возможность масштабирования из-за использования jvm? Jms это как вариант, но если вы заставите все классы вашего приложения для каждого вызова метода дергать jms, то ваше приложение умрет смертью храбрых. Кроме того насколько я помню надо будет быть очень аккуратным с выбором сервера и драйвера к нему, потому что очень многие драйвера на каждый listener создают новый поток для обработки, что черевато.
Похоже я не совсем так объяснил что это и для чего. Акторы это внутренние объекты, из которых строится в основном ядро бизнес логики. Remote actor позволяют размазывать это ядро по нескольким машинам. Но это никак не относится к уровню представления, например rest сервисам.
Безусловно rest api позволяет дергать actor для выполнения каких-то действий, но oauth и подобное, полностью ортогонально концепции actor и никак с ними не пересекается.
Ну и здесь он не сделал исключения :) Начал с того, что не надо лебизить перед менеджерами и первым пунктом поставил оценку навыков от менеджера.
А так PKI есть везде и он рассказал как он крут что их использует.
У меня на OpenJDK 6 получается такая картина — если запускать от пользователя ваш код, то получается из tcpdump
18:20:30.505886 IP 192.168.0.188.49302 > www.yandex.ru.echo: Flags [S], seq 2605630052, win 14600, options [mss 1460,sackOK,TS val 3859659 ecr 0,nop,wscale 4], length 0
И отваливается по таймауту. А если пускать как sudo то
18:20:42.716477 IP 192.168.0.188 > www.yandex.ru: ICMP echo request, id 10651, seq 8883, length 44
Так что получается, что все работает как и описано, только надо для java поставить suid, а этого обычно не делают и похоже делать не будут. Но я бы поменял на эту реализацию, потому что не надо нативы таскать с собой. И кстати пинги получаются нормальные
true 32 ms
true 29 ms
true 27 ms
true 27 ms
true 34 ms
true 27 ms
true 26 ms
true 24 ms
true 18 ms
А по поводу github. Я тоже везде где могу использую меркуриал, но хаб он богат community и если очень надо, то есть hg-git.
А про реализацию надо почитать чуть-чуть внимательнее
A typical implementation will use ICMP ECHO REQUESTs if the privilege can be obtained, otherwise it will try to establish a TCP connection on port 7
Время его выполнения будет через System.currentMillis(). Не думаю что от тестовой утилиты требуется точность в наносекундах для определения пинга. Как по мне так нужно его наличие, порядок величин и количество потерь. А будет там 67 или 72 мс — не принципиально.
Sep 16, 2011 12:07:21 AM ru.krasu.edhel.jim.win.Worker onError
WARNING: Operation not permitted
java.io.IOException: Operation not permitted
at org.savarese.rocksaw.net.RawSocket.__throwIOException(RawSocket.java:183)
at org.savarese.rocksaw.net.RawSocket.open(RawSocket.java:263)
at ru.krasu.edhel.jim.util.Ping$Pinger.(Ping.java:93)
А так лучше на github выложить — полезная штука.
Про один поток на листенер это черевато вот чем — что будет когда у вас система будет работать с 1000 листнеров? Или с 10000? Так как акторы работают в пуле то для них это не имеет значения
У самих акторов есть методы postStart preStop чтобы сохранять-восстанавливать состояние по необходимости.
А игры наиболее интересный с точки зрения пример, где любые другие подходы не тянут. Например, если у нас есть ферма, то для каждого объекта можно создать актор для обработки событий для него. Т.е. для каждого деревца, каждого кустика будет свой concurrent обработчик, который реагирует на действия разных игроков, и при этот система не умрет от огромного количества потоков.
Безусловно rest api позволяет дергать actor для выполнения каких-то действий, но oauth и подобное, полностью ортогонально концепции actor и никак с ними не пересекается.
А так PKI есть везде и он рассказал как он крут что их использует.
www.flickr.com/photos/57605784@N06/5305724423/