Пытаясь разобраться с RTPproxy и особенно с ее протоколом управления, написал свой вариант на erlang:

http://code.google.com/p/erlrtpproxy/

Это утилита для OpenSER/SER, чтоб соединять RTP-потоки у SIP-клиентов, находящися за симметричным(и) NAT'ом.

Что работает:

* Полностью заменяет RTPproxy в случае звонков с одним RTP-потоком (без видео, например)
* Прозрачно для пользователя работает одновременно на множестве erlang-узлов

TODO:

* Проксирование более одного rtp-потока (пока просто не нашел времени чтоб сделать и протестировать, но нужно сделать - микрософтовый RTC умеет видео, причем неплохо) (надо потестить получше)
* Проигрывание определенного, заранее записанного RTP-потока (для проигрывания в early media мы используем SEMS - у нас там статические правила)
* Вообще, сделать обработку дополнительных аргументов при соединении пользователей (надо посмотреть, что там есть)
* Запись RTP-потока (наверное придется сделать)
* Переупаковка RTP-потока для линий с плохим качеством (надо сделать)
* Получение статистики (надо б сделать, пожалуй - заодно и балансировать получится получше, чем round-robin'ом)
* Добавление и убавление списка узлов без перезапуска (надо срочно доделать)

А так - пашет у нас уже дней 20.

Надо еще думать, может-ли быть такое, чтоб адрес и порт источника RTP в процессе разговора сменялся? Ну, может бывают такие симметричные NAT'ы.

Вышел Erlang R12B-0.

Москвичам нужно работать ближе к дому.

Издеваться над кабыздохами запретят, хотя не запретят научные эксперименты, хехехе.

LJR наконец-то переехал в Благословенный Валинор.

Шведы проанализировали деятельность Санта-Клауса (по наводке grp63@lj).

Лайф гоуз он!

Вот, в erlang-general разговаривают о unit-тестах. В процессе общения Joe Armstrong высказал идею, до которой я как-то и не догадывался, что можно считать unit-тесты стандартной частью самого языка.

http://thread.gmane.org/gmane.comp.lang.erlang.general/25815/focus=25825

Походу это не только фича erlang'а, но и всех языков, где оператор сравнения может выбрасывать ошибку.

Вот, передают западные голоса:

http://www.eetimes.com/news/design/showArticle.jhtml?articleID=202102427

Пишут, что сейчас все шире и шире внедряются многоядерные процы, а программеры пишут по старинке, на C и С++, что не помогает (а то и просто мешает) использовать многоядерность. Отчего-то делают вывод, что языков со встроенным параллизмом для embedded нету. Как так нету? А Erlang?

Но, походу, проблема все-равно остается, т.к. куча всего уже написана без оглядки на многоядерность, да и писать на Erlang непросто сходу. Вот, Tim Bray попытался сравнить, насколько шустр Erlang по сравнению с Ruby и увидел, что последний в 10 (!) раз шустрее. Конечно, нашелся человек, который все переписал, и разогнал ту тимбреевскую программулинку в 60 раз, но так ведь надо знать, где ударить.

Вообще, тема параллелизма стала совсем уж актуальной - раньше ею интересовались только дипломированные числодробильщики из университетов, а теперь даже в мобиле есть пара ядер.

Кстати, вот, люди из Intel пишут забавное:

http://blogs.intel.com/research/2007/10/parallel_programming_environme.html

Они пришли к выводу, что способов писать параллельное ПО так много, что лучше не выбирать среди имеющихся вариантов, а придумать еще один, хехехе. Эту тему обсудили в Erlang-Questions:

http://thread.gmane.org/gmane.comp.lang.erlang.general/24417

Скачал pdf про преступления против человечества. Какая-то мегакнижка в более чем тыщу страниц. Буду читать и разглядывать картинки.
По наводке тов. dadrov@lj узнал о венграх удивительное - они завели танк (Т-34) и в знако протеста против русских ездят на нем по Будапешту. На танке, конечно, весело и по-щегольски.

Дописал мегаутилиту на erlang'е - дочищу ее, добавлю обработку кой-каких исключительных ситуаций и в продакшн. Erlang рулит! Буду и дальше им пользоваться, чем буду повышать свою квалификацию.

На одной из прошедших тренировок слегка травмировал левую кисть (выбил мизинец). Неособо круто - Когда отжимаешься на кулаке, то неприятное ощущение заставляет тебя расслабить руку, чем, с очевидностью, снижает твои способности. И уже неделю так. Но переживем, ничего...

На "Русский марш" иду. А как же! И всяких разных слушать не буду.

xpost to programming.
Приветствую!

Что-то я недопонял. Как заставить выполнить кусок кода, скажем, шесть раз.

Дано:

unixODBC, откуда я читаю записи вот так:

main_cycle (Ref) ->
	case odbc:select_count(Ref, "select A,B,C from name.table") of 
		{ok, NumberOfRows} ->
			if 
				NumberOfRows > 0 ->
					select_calls(Ref)
			end;
		Error -> 
			exit(Error)
	end.

В вышеуказанной функции я получаю NumberOfRows например равным шести. Я не нашел ничего лучше, как рекурсивно выполнить select_calls до тех пор, пока мне не сообщат об ошибке:

select_calls(Ref) ->
	case odbc:next(Ref) of 
		{selected,["CS_CALLED_STATION_ID","CS_CALLING_STATION_ID","CS_LOCALCALLID"], [{Caller,Called,SessionID}]} ->
			write_msg(Caller,Called,SessionID),
			select_calls(Ref);
	Error -> 
		io:format("end of data\n")
	end.

Запросить сразу лист записей, а потом сделать map или foreach нельзя, т.к. драйвер базы данных (Oracle) для unixODBC еще не дописан до конца (а фирменный от Oracle или другой коммерческий от Easysoft настолько проблемно ставится, что проще будет пока с этим повозиться) и не позволяет селектом выдавать сразу лист - только так, по одной записи.

Так вот, хотелось бы не дожидаться пока odbc:next выбросит ошибку, а выполнить его столько, сколько мне надо.

Как?
А то я что-то этот момент упустил пока. В туториалах есть много-много про параллельное программирование и кластеризацию ,а вот такой момент что-то обойдет вниманием.

Я хотел добавить лишний параметр в вызов функции, что-то вроде

select_calls(Ref, counter) ->
	if
		counter > 0 ->
			...
			select_calls(Ref, counter-1);
	end.

но это почему-то не работает.

Есть смотрелка для геоданных ArcExplorer от конторы ESRI. Написана она на Java. К java я как-то без пиетету относился, ну язык, как язык - мало ли языков, а еще и тормозной кое-где, однако я пропускал самую фичастую фичу.

Итак, берем, качаем эту штуку:

http://gis.esri.com/download/index.cfm?downloadid=358

33 метра (внутрь догадались запаковать jre), все дела.

На х86 все работает. Затем берем и переносим все как есть на PowerPC. Ну тут сложность - единственная Java VM, которая заработала на PowerPC-Linux, это Blackdown Java 1.3.1, а официально требуют JRE версии 1.4.2, но, вроде как, все работает и на 1.3.1

В общем берем, копируем файлы, и видим, что все работает! I'm impressed! Честно говоря так и не верил, что они делают реально переносимый код, причем без проблем с BigEndian/LittleEndian. Переносимость в смысле на одной процессорной архитектуре, но на разных операционках мы уже видали - нас этим не удивить. Но переносимость между процессорными архитектурами... Я думал, что так только Erlang умеет.

Drawback, это скорость выполнения (теоретически), но на практике я проблем не заметил. В общем java, это тоже хорошо.

Недавно в comp.lang.erlang.general проскочило любопытное сообщение:

http://thread.gmane.org/gmane.comp.lang.erlang.general/17602/focus=17602

Парнишка пишет, что он применил этот язык для разработки специальной приблуды для метро в Лионе.

У читателей возник вопрос:

http://thread.gmane.org/gmane.comp.lang.erlang.general/17624/focus=17624

Как ему удалось обьяснить начальству, что Erlang - хороший вариант (ведь все слышали только про C++ и Java). Оказвается он рассказал начальству, что есть такая библиотека, написанная на языке С, как Erlang :). Подписчики этого списка рассылки развеселились, и один из них рассказал веселую историю:

http://article.gmane.org/gmane.comp.lang.erlang.general/17682

Консультант "К" должен был написать программу для организации "О". "О" требовала, чтоб программа была написана на языке "Я". А "К" имел мнение, что Prolog - подходящий язык для этой работы, но "Я" не был Prolog'ом. Тогда "К" написал Prolog-интерпретатор на языке "Я", который и представил как "программа", а настоящая программа на Prolog'е была названа "конфигурационными даными" :)

Вот так бывает :)

Не работал ODBC (через unixODBC) в ejabberd. Ну я и так, и этак конфиги ковырял - все без толку (да и конфигов немного - ковырять неинтересно). А оказалось, что erlang собрался без поддержки ODBC.

Во-1, его надо собирать с --enable-odbc, но этого мало. Покопавшись в гугле, я обнаружил, что ему не хватает специального бинарника odbcserver, который почему-то так и не был собран. Еще покопавшись, я узнал, что на 64-битных машинах он не собирается вовсе.

На самом деле собирается, но только с этим патчем:

--- lib/odbc/c_src/Makefile.in	2006-05-03 12:18:45.000000000 +0400
+++ lib/odbc/c_src/Makefile.in	2006-08-02 14:21:13.000000000 +0400
@@ -57,11 +57,11 @@
 WIN32_TARGET = $(WIN_BIN_DIR)/odbcserver.exe
 EXE_TARGET = $(WIN32_TARGET)
 else
-ifneq ($(BITS64),yes)
+#ifneq ($(BITS64),yes)
 EI_LIB = -lerl_interface -lei
 UNIX_TARGET = $(BIN_DIR)/odbcserver
 EXE_TARGET = $(UNIX_TARGET)
-endif
+#endif
 endif
 
 C_FILES = odbcserver.c 

Я не уверен, что правильно поступаю так грубо разрешив ему компилироваться, но пока (пару часов) все работает.

Есть такой функциональный язык программирования, как Erlang. На нем пишут высоконадежный сетевой софт. Я тут нашел забавное - сабж:

http://erlang.org/faq/quick_start.html

В конце этого документа рекомендуют перейти к написанию игр. Но оцените-ка обьем текста :)