Здравствуйте, Gaperton, Вы писали:

G>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.

Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было.

G>Вообще непонятно, зачем ты споришь с очевидным. Так сложно пережить факт, что Эрланговский рантайм содержит лучшую на текущий момент поддержку параллельного программирования? Извини, люди специально старались, чтоб было именно так, что тут удивляться. Старались они потому, что считали, что это очень важно. И не идиоты люди-то — заслуженные инженеры, с опытом, понимают, что делают. Можно допустить, что тут есть какая-то полезная фишка? Или все отстой, кроме пчел?

Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.

Здравствуйте, eao197, Вы писали:

E>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.

Очень субъективно, но по мне выделенное говорит о несколько скептическом отношении к возможным бенефитам, а если загодя считаешь вариант проигрышным, то как-то даж не знаю

Здравствуйте, Курилка, Вы писали:

E>>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.

К>Очень субъективно, но по мне выделенное говорит о несколько скептическом отношении к возможным бенефитам, а если загодя считаешь вариант проигрышным, то как-то даж не знаю

Термин "круто" здесь был мной упомянут в самом лучшем смысле этого слова. Читая Армстронга видишь правильные вещи, и наблюдая как эти вещи находят воплощение в Erlang-е, невольно говоришь про себя: "круто".

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

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

Здравствуйте, BulatZiganshin, Вы писали:

G>>Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики.

BZ>как человек, написавший пару библиотек сериализации на хаскеле, я протестую против наглой и циничной лжи!
В чем ложь? В том, что при динамике не нужны фабрики, а при статике нужны? Обвиняешь в "наглой и циничной лжи" — отвечай за базар. А лучше — сначала думай, потом пиши, или (на выбор) веди себя прилично, тогда и отвечать за базар не придется.

BZ>правда, тип для десериализации всё равно знать приходится
Да ты что . Неужели? А обработку версионности сообщений ты учесть не забыл — прикольная такая штука получается, когда у тебя десериализатор съезжает с бинарного формата из-за ошибки версий — никогда не втречал такого?

BZ>но в языке с действительно строгой типизацией это обычно и не является проблемой
Для меня код сериализации-десериализации проблемой не является на любом языке, в т.ч. и на plain C — слишком много раз в жизни я его писал. И что? Не, право слово, смешные вы люди — вы правда думаете, что люди, знающие Эрланг, ни на чем другом не писали никогда, да? И вы им тайну откроете, когда расскажете, как десериализация делается в других языках?

Краткий курс "десериализации" в Эрланге. Это будет непросто, конечно не так просто, как "в нормальном строготипизированном языке", но я думаю, поднапрягшись можно что-то понять и научится этому непростому делу в динамике.

Способ первый — из бинарного источника:
DeserializedData = binary_to_term( Binary ).

Способ второй — "десериализуем" принятое процессом сообщение:
DeserializedData = receive MyData -> MyData end.

Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это все-таки непростая штука.

G>Краткий курс "десериализации" в Эрланге. Это будет непросто, конечно не так просто, как "в нормальном строготипизированном языке", но я думаю, поднапрягшись можно что-то понять и научится этому непростому делу в динамике.

А Эрланг все же строго типизированый язык Только не статически типизированый

Здравствуйте, Gaperton, Вы писали:

[cut]

G>Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это
все-таки непростая штука.

Слушай, а вот как Эрланг с версионностью борется?
Скажем апгрейдим сервер, формат сообщений расширился, т.е. под старый шаблон уже не "влезает" — придётся принудительно апгрейдить клиентов? Или в формате делать "точки расширения" (e.g. параметр как список произв. длины, я тут рядом вроде eao197 приводил подобную схема)? Не встречался с подобной задачей?

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, Gaperton, Вы писали:

G>>Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.

EC>А имеет смысл писать сервер аналогичный CQG'шному на erlang? Если да, то в чём будет выигрыш и проигрыш? Если можно с примерными количественными оценками.

Плюсов можно достичь таких:
1) Хорошую реактивность — с этим много неприятных багов было. В решении на Эрланге таких багов должно быть меньше.
2) Отличную масштабируемость — можно спроектировать так, чтобы решение кластеризовалось. На С++ это сделать тяжело.
3) И просто классную, небо и земля по сравнению с текущим сервером — отказоустойчивость и отработку ошибок. Шутка ли — крэш по одному из клиентов не влияет на остальных. Это означает резкое сокращение количества ошибок, вызывающих крэш и соотвественно отказ сервиса всем клиентам, и понижение приоритета таких ошибок. Мэйнтененс вздохнет свободнее.
4) Также, удалось бы сократить цикл исправления ошибок в сервере — это очень классно. Можно на живой системе отлаживаться, патчи накатывать, и смотреть, что получается — жутко удобно.
5) Динамический язык — означает легкость логгирования и анализа креш-дампов — подсистема мониторинга и логгирования будет очень удобна без особых на это затрат.

Минусы такие:
Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках. При проектировании предстоит решить много архитектурных и алгоритмических проблем — например, временная синхронизация, или обработка временных рядов с переменной временной шкалой. Грубо говоря, я не знаю, и не могу заранее знать, с какими проблемами я столкнусь, затеяв переписывание его на Erlang (очевидно, без вставок на С++ будет не обойтись — чувствую. Однако где они будут — хоть примерно? Have no fuckin idea). Я не могу оценить трудозатраты. Для этого надо иметь очень большой опыт.

Резюмируя — я бы стартовал пилотный проект с парой людей, чтобы они пописали прототипов. И посмотрел, что получается.

Вот в институтах есть хороший классификатор проектов по степени риска, чтоли. НИР (научно исследователские работы — результат — отчеты канают), и ОКР (опытно-конструкторские работы — это обычный инженерный проект, конкретную штуковину проектируют для полезных применений), и НИОКР (это и то и то сразу — результат — прототипы, опытные образцы, но ни о каком production-качестве речь не идет).

Так вот, я бы стартовал на эту тему НИОКР. Цель которого — выявить оптимальные архитектурные подходы и свойства решений сервера на базе Erlang, результат — работающий прототип + отчет с исследованиями его свойств и выводами. А по результатам — решил, надо ли переписвать сервер или нет.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Gaperton, Вы писали:

G>>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.

E>Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было.
Я так понимаю, ты просто не понимаешь смысл вышесказанного, и сути озвученных проблем. И сказать тебе по существу нечего — ни по поводу агентов, ни по поводу процессов.

E>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.

Ну так бы сразу и сказал. А я-то думал тебе какую-то работу на языках программирования делать надо, время на тебя тратил.

У Эрланга степен крутизны невелика — он не крут совсем. На чем там ты сейчас пишешь? Ruby? Вот, Ruby в сто раз круче. И этот, как его, Питон — тот круче в двести раз. Я уж молчу о немерле — этот ваще круче вареных яиц. Все?

G>У Эрланга степен крутизны невелика — он не крут совсем. На чем там ты сейчас пишешь? Ruby? Вот, Ruby в сто раз круче. И этот, как его, Питон — тот круче в двести раз. Я уж молчу о немерле — этот ваще круче вареных яиц. Все?

Ну, не стоит недооценивать степень крутизны Эрланга. Я сейчас на Google Alerts подписан по Эрлангу. Последние пару недель процентов 90 сообщений — о реализации/возможности реализации многопоточности a la Эрланг в языках типа Руби и Питон.

Всуе и не всуе Эрланг сейчас в разных конференциях (типа .declarative, .scheme, .ruby и проч.) упоминается чуть ли не чаще, чем в, собственно, .erlang-general

Призрак бродит по Инету, призрак легкой многопоточности

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Gaperton, Вы писали:

К>[cut]

G>>Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это
К>все-таки непростая штука.

К>Слушай, а вот как Эрланг с версионностью борется?
К>Скажем апгрейдим сервер, формат сообщений расширился, т.е. под старый шаблон уже не "влезает" — придётся принудительно апгрейдить клиентов? Или в формате делать "точки расширения" (e.g. параметр как список произв. длины, я тут рядом вроде eao197 приводил подобную схема)? Не встречался с подобной задачей?

Есть на самом деле две проблемы, связанные с версионностью. Первая — десериализатор бинарного потока съезжает (из-за изменившейся длины и/или формата пакетов), и начинает работать не начала пакетов. Это кирдык. Этой проблемы у нас не будет в принципе при применении встроенной сериализации. Вторая проблема — как обрабатывать сообщения неизвестного формата. Это уже проблема прикладная. "Хорошее" поведение — пропускать пакеты неизвестного типа, и пропускать неизвестную расширенную информацию в измененных пакетах.

Пропускаем неизвестные сообщения мы так:

receive
   { msg1, ... } -> ...
   { msg2, ... } -> ...
   ...
   _ -> skip_unknown_message;
end

Это рекомендовано в практике кодирования.

Расширенная информация — либо списком передаем поля, как ты говоришь, либо — тоже списком, но на туплах, либо комбинация.

receive
   { msg1, Param1, _ExtendedInfoForFutureUse } -> ...
   { msg2, Param1, [ { ExtInfo1, ExtInfo2 } | _ ] } -> ...
   { msg3, Param1, { ExtInfo1, ExtInfo2, _ExtendedInfoForFutureUse } } -> ...
   ...
   _ -> skip_unknown_message;
end

Но так чаще всего не делают. Лучше завести новый тип сообщения, который будет спокойно игнорироваться.

А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.

Здравствуйте, Gaperton, Вы писали:

G>А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.

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

Здравствуйте, Gaperton, Вы писали:

G>Плюсов можно достичь таких:
Т.е. всякие сервисы, которые слушают обновления рыночных данных, что-то пересчитывают и шлют дальше это подходящая задача?

G>Минусы такие:
G>Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках.
Ты имеешь в виду, что опыт ОО проектирования накоплен больше чем проектирования на функциональных языках и это в данном случае проблема?

Ты часто упоминаешь временные ряды в контексте сервера CQG. Можешь привести минимальный пример задачи, чтобы понять, что имеется в виду?

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Gaperton, Вы писали:

G>>А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.

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

Тогда надо принимать/отправлять данные по сокету. Он оперирует бинарисами. Делается это примерно так:

encode_term( YourData ) -> 
  SerializedData = term_to_binary( YourData ),
  << size( SerializedData ):16, SerializedData >>.

decode_binary( << Size:16, Rest/binary >> ) ->
  << BinTerm:Size/binary-unit:8, Rest2/binary >> = Rest,
  { binary_to_term( BinTerm ), Rest2 }.

Последняя функция предполагает, что длины binary хватает на декодирование. В реальности она будет чуть сложнее — но думаю принцип понятен.

Если клиент не Эрлаговский, мы реализуем и бинарный протокол (напугали ежа голой жопой, извините ). Тут Эрланг, разумеется, порвет ваще всех безоговорочно, но не за счет динамики, а за счет binaries.

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, Gaperton, Вы писали:

G>>Плюсов можно достичь таких:
EC>Т.е. всякие сервисы, которые слушают обновления рыночных данных, что-то пересчитывают и шлют дальше это подходящая задача?
В принципе да, с одной оговоркой. Обработка там конечно тривиальная, но как бы тормознутость Эрланга не стала проблемой. Потому, что тут важна минимальная задерка и высокая пропускная способность, а задача обработки потока котировок не так чтоб сильно хорошо параллелилась. В принципе, можно параллелить ее по т.н. коммодити (группа инструментов) и по инструментам, но это приводит к появлению большого количества несинхронизированных по времени потоков котировок. Короче — как я сказал хз, надо прототипировать. Здесь все упирается в нахождение внятного и приемлемого способа отпараллелить задачу.

Далее, надо понимать, что обработка рыночных данных — это группа разных задач.
1) "Парсеры" — преобразователи потоков котировок из одного формата в другой. Эта задача хорошо решается на Эрланге — так делают в futuresource.
2) Сервис по обработке онлайновых заявок на торговлю (электронные торги) — должен лечь на Эрланг идеально, понятно в целом как делать.
3) Сервер по обработке исторических данных и их изменениях в реальном времени — надо думать.

Сервисов возможно довольно много — это я на вскидку привел.

G>>Минусы такие:
G>>Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках.
EC>Ты имеешь в виду, что опыт ОО проектирования накоплен больше чем проектирования на функциональных языках и это в данном случае проблема?
Я имею в виду, что лично я не умею проектировать большие системы конкретно на Эрланге. Проектирование Эрланг-систем имеет мало общего с проектированием на ФЯ — это почти ОО проектирование, только каждый объект работает параллельно и довольно крупный. Плюс — при проектировании надо учитывать грабли и ограничения Эрланг-системы, а для этого нужен опыт. Армстронг бы с этой задачей справился влет, я — нет.

EC>Ты часто упоминаешь временные ряды в контексте сервера CQG. Можешь привести минимальный пример задачи, чтобы понять, что имеется в виду?
Временной ряд — это упорядоченная по времени последовательность некоторых данных. Типичный для биржевой обработки пример — последовательность четверок Open, High, Low, Close по времени с интервалом, например, 60 минут. Open — Close — первая и последняя котировки за час, High Low — максимальная и минимальная за час. Эта черверка называется bar. Временные ряды могут преобразовываться, например я могу на ряд баров наложить индикатор "скользящее среднее с периодом 5", и получу другой временной ряд, из единственного числового значения MA. При этом, последнее значение OHLC 60 обновляется в реальном времени из потока котировок, должен обновляться и зависящий от него временной ряд MA. Сервер CQG умеет лениво вычислять временные ряды по запросу за период времени, логически же они бесконечны. Сервер содержит систему их кэширования, умеет отслеживать зависимости, поддерживает разные типы временных рядов и аналитической обработки.

Здравствуйте, Gaperton, Вы писали:

G>Есть на самом деле две проблемы, связанные с версионностью. Первая — десериализатор бинарного потока съезжает (из-за изменившейся длины и/или формата пакетов), и начинает работать не начала пакетов. Это кирдык. Этой проблемы у нас не будет в принципе при применении встроенной сериализации. Вторая проблема — как обрабатывать сообщения неизвестного формата. Это уже проблема прикладная. "Хорошее" поведение — пропускать пакеты неизвестного типа, и пропускать неизвестную расширенную информацию в измененных пакетах.

Первая проблема существует только для тех encoding rules, которые не оставляют меток в сериализованном потоке, а расчитывают исключительно на порядок следования элементов. Например, ASN1 PER и различные доморощенные способы сериализации. Для таких encoding rules незапланированное расширение протокола в общем случае невозможно. Поэтому в описании сериализуемых данных требуется указывать специальные extension points. Например, в ASN1 DDL для этого предназначены специальные синтаксические правила.

При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.

Поэтому страхи по поводу кирдыка, в общем случае преувеличены

Чтоже до пропуска пакетов неизвестного типа или неизвестной расширенной информации, то и здесь не все так просто. Так что слово "хорошее" не зря было взято в кавычки. Имхо, гораздо лучше, когда расширенная информация снабжается специальным флагом mustUnderstand. Принимающая сторона имеет право пропускать или игнорировать только ту расширенную информацию, для которой флаг mustUnderstand установлен в false.

Здравствуйте, Gaperton, Вы писали:

G>>>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.

E>>Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было.
G>Я так понимаю, ты просто не понимаешь смысл вышесказанного, и сути озвученных проблем. И сказать тебе по существу нечего — ни по поводу агентов, ни по поводу процессов.

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

E>>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.

G>Ну так бы сразу и сказал. А я-то думал тебе какую-то работу на языках программирования делать надо, время на тебя тратил.

Извини, что отнял у тебя время.
Тем не менее, интересно было выслушать мнение об Erlang-е не из работы Армстронга, а от кого-то, кто Erlang использует (кстати, использует ли?).

Здравствуйте, IT, Вы писали:


IT>Нет. Обычный браузерный javascript.

Script#

Здравствуйте, Gaperton, Вы писали:

G>Сервисов возможно довольно много — это я на вскидку привел.
А всякая расчётная кухня типа интерполяции или симуляции методом Монте-Карло и прочие вещи для моделирования в финансах?

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, Gaperton, Вы писали:

G>>Сервисов возможно довольно много — это я на вскидку привел.
EC>А всякая расчётная кухня типа интерполяции или симуляции методом Монте-Карло и прочие вещи для моделирования в финансах?
Этого на практике немного — по крайней мере в приложениях CQG рассчитанных не на инвестиционные банки и не на арбитраж, а на обыкновенных трейдеров. Понятное дело, числодробилки лучше писать на С++. И сложность не в них. Большинство трейдеров применяют элементарные, довольно простые рассчеты.

Здравствуйте, eao197, Вы писали:

E>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.

E>Поэтому страхи по поводу кирдыка, в общем случае преувеличены
Это не "страхи", и они не преувеличены. При собственной реализации сериалиации-десериализации ручками ты внесешь ошибки, которые могут привести к съезжанию потока, независимо от того, какой подход к сериализации ты применяешь, и обнаружить такую ошибку а также восстановиться после нее не так просто. Для этого в поток magic-и вводят, специальные метки. Спасает от таких ошибок только автоматически генерированные сериализаторы.

Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.

XML и текстовые языки разметки, которые казалось бы решают проблемы сериализации, и которые ты упомянул — классная штука, только его декодирование примерно в 50 раз медленнее, чем декодирование бинарных форматов, и он не по детски жрет траффик, что неприемлемо для целого ряда приложений. Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.

ASN.1 с применением автоматических генераторов позволяет таких ошибок избежать. К слову, в стандартной поставке Erlang/OTP поддержан ASN.1 (что неудивительно для Open Telecom Platform).

E>Чтоже до пропуска пакетов неизвестного типа или неизвестной расширенной информации, то и здесь не все так просто. Так что слово "хорошее" не зря было взято в кавычки. Имхо, гораздо лучше, когда расширенная информация снабжается специальным флагом mustUnderstand. Принимающая сторона имеет право пропускать или игнорировать только ту расширенную информацию, для которой флаг mustUnderstand установлен в false.

Здесь как раз все достаточно просто. Если ты не понимаешь расширенную информацию, тебе придется либо ее проигнорировать либо умереть при попытке ее разобрать. Флаг mustUnderstand в результате нужен только для того, чтобы убить потребителя. Есть более простые и прямолинейные способы определить, что верисии клиента-сервера несовместимы, которые все и применяют — достаточно при хендшейке обменяться версиями протоколов, и сообщить о несовместимости культурным образом.