April 2008 Archives
Меня чертовки раздражает CLI, в котором не работают ^U и ^W. Просто выводит из себя. Я долго мирился с этим безобразием в erlang shell, но наконец не вытерел.
Рецепт:
1. Взять edlin.erl из сорцов, скопировать к себе. У меня для этого есть ~/elib
2. Наложить патч
--- /home/dg/erlang-R12B-1/otp_src_R12B-1/lib/stdlib/src/edlin.erl 2007-11-26 21:55:31.000000000 +0300
+++ /home/dg/elib/edlin.erl 2008-04-23 00:11:31.000000000 +0400
@@ -164,6 +164,7 @@
key_map($\^T, none) -> transpose_char;
key_map($\^U, none) -> ctlu;
key_map($\^], none) -> auto_blink;
+key_map($\^W, none) -> backward_kill_word;
key_map($\^X, none) -> ctlx;
key_map($\^Y, none) -> yank;
key_map($\e, none) -> meta;
@@ -242,6 +243,9 @@
do_op(kill_line, Bef, Aft, Rs) ->
put(kill_buffer, Aft),
{{Bef,[]},[{delete_chars,length(Aft)}|Rs]};
+do_op(ctlu, Bef, Aft, Rs) ->
+ put(kill_buffer, Bef),
+ {{[],Aft},[{delete_chars,-length(Bef)}|Rs]};
do_op(yank, Bef, [], Rs) ->
Kill = get(kill_buffer),
{{reverse(Kill, Bef),[]},[{put_chars,Kill}|Rs]};
3. Компильнуть
4. alias erl="erl -pa ~/ebin"
5. Грабить корованы.
Рецепт:
1. Взять edlin.erl из сорцов, скопировать к себе. У меня для этого есть ~/elib
2. Наложить патч
--- /home/dg/erlang-R12B-1/otp_src_R12B-1/lib/stdlib/src/edlin.erl 2007-11-26 21:55:31.000000000 +0300
+++ /home/dg/elib/edlin.erl 2008-04-23 00:11:31.000000000 +0400
@@ -164,6 +164,7 @@
key_map($\^T, none) -> transpose_char;
key_map($\^U, none) -> ctlu;
key_map($\^], none) -> auto_blink;
+key_map($\^W, none) -> backward_kill_word;
key_map($\^X, none) -> ctlx;
key_map($\^Y, none) -> yank;
key_map($\e, none) -> meta;
@@ -242,6 +243,9 @@
do_op(kill_line, Bef, Aft, Rs) ->
put(kill_buffer, Aft),
{{Bef,[]},[{delete_chars,length(Aft)}|Rs]};
+do_op(ctlu, Bef, Aft, Rs) ->
+ put(kill_buffer, Bef),
+ {{[],Aft},[{delete_chars,-length(Bef)}|Rs]};
do_op(yank, Bef, [], Rs) ->
Kill = get(kill_buffer),
{{reverse(Kill, Bef),[]},[{put_chars,Kill}|Rs]};
3. Компильнуть
4. alias erl="erl -pa ~/ebin"
5. Грабить корованы.
Сегодня решил саморазвлечься и проделать эксперимент, до которого все никак не доходили руки. Эксперимент без всякой практической ценности, но тем он и хорош. Полезными делами можно заниматься на работе, а развлекаться надо всякими глупостями.
Как-то я писал про истерику М. Литвинович по поводу "блокировки" оппозиционных сайтов. Если помните, одним из замеченных моментов там был изменяющий TTL в пределах TCP-сессии. В порядке общего любопытства я сегодня сляпал простенький сниффер, который смотрит на пробегающие мимо TCP-потоки и докладывает о тех из них, в которых меняется TTL IP-пакетов.
Кое-чего наловилось.
Например, знаменитый Comcast'овский способ "регулирования" P2P-трафика. Они ресетят те TCP-сесии, которые им почему-то не нравятся, но вот правильный TTL в RST они подставить забывают. В принципе, пользуясь этим фактом, можно бороться с этим "регулированием". Достаточно дропать RST с "левым" TTL. False positives быть могут, но они довольно маловероятны. Очевидно, дропать такие RST должны оба пира. Вот пример такой сессии: comcast-rst.pcap
А вот http://ibm.com ведет себя крайне интересно. Вот pcap-файл: ibm.com.pcap. За одну сессию TTL пакетов, которые идут оттуда, поменялся 19 раз! Похоже, что это какой-то жутко умный load-balancer. Который как-то раскидывает разные запросы одной keepalive'нутой HTTP-сессии. Но я никак не пойму, по какому принципу он это делает, и, как он потом это собирает и почему он прокидывает эти запросы "прозрачно". Идеи?
Как-то я писал про истерику М. Литвинович по поводу "блокировки" оппозиционных сайтов. Если помните, одним из замеченных моментов там был изменяющий TTL в пределах TCP-сессии. В порядке общего любопытства я сегодня сляпал простенький сниффер, который смотрит на пробегающие мимо TCP-потоки и докладывает о тех из них, в которых меняется TTL IP-пакетов.
Кое-чего наловилось.
Например, знаменитый Comcast'овский способ "регулирования" P2P-трафика. Они ресетят те TCP-сесии, которые им почему-то не нравятся, но вот правильный TTL в RST они подставить забывают. В принципе, пользуясь этим фактом, можно бороться с этим "регулированием". Достаточно дропать RST с "левым" TTL. False positives быть могут, но они довольно маловероятны. Очевидно, дропать такие RST должны оба пира. Вот пример такой сессии: comcast-rst.pcap
А вот http://ibm.com ведет себя крайне интересно. Вот pcap-файл: ibm.com.pcap. За одну сессию TTL пакетов, которые идут оттуда, поменялся 19 раз! Похоже, что это какой-то жутко умный load-balancer. Который как-то раскидывает разные запросы одной keepalive'нутой HTTP-сессии. Но я никак не пойму, по какому принципу он это делает, и, как он потом это собирает и почему он прокидывает эти запросы "прозрачно". Идеи?
Что-то я выпал из текущих событий - четыре командировки и два гриппа подряд. Ни новости нормально не почитать, ни в блог не пописать. Будем наверстывать.
Я как-то упоминал про P4P. Вот замечательная новость трехнедельной давности: Verizon touts smart P2P software.
Очень хочется надеяться, что остальные пойдут по тем же стопам.
Я как-то упоминал про P4P. Вот замечательная новость трехнедельной давности: Verizon touts smart P2P software.
Using network topology data from Verizon and Telefonica, Yale University tested a software enhancement to the peer-to-peer protocol that it developed with software developer Pando Networks.
What the researchers discovered was that when using the so-called P4P software they were able to reduce the impact of peer-to-peer traffic on Verizon's network by more than 50 percent. This is significant because peer-to-peer traffic makes up roughly half of all traffic traveling over Verizon's network.
....
He said that when the P4P software was used on the Verizon network it found that 58 percent of its peer-to-peer network traffic stayed local. Using regular P2P technology, only 6 percent of the traffic stayed local.Это очень, очень хороший результат. И шаг в правильном направлении. Аплодисменты Верайзону.
Очень хочется надеяться, что остальные пойдут по тем же стопам.