[C++] протокол Diameter

пофиксите то что не собирается
или напишите свою, там с десяток строк - не осилите?

/usr/lib/erlang/lib/diameter-0.9/

>/usr/lib/erlang/lib/diameter-0.9/

меня слово erlang смущает в пути

>там с десяток строк - не осилите?

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

>пофиксите то что не собирается

сомнительное удовольствие, ибо фиксить дохрена, еще не факт что работать в итоге будет

> вот значит почему все нормальные реализации diemeter-стека коммерческие, пустяковое дело, зачем открытые либы писать, кому надо сам напишет...там ведь строк десяток

коммерческие еще хуже, ничего нормального в них нет
а что вы считаете что диаметр такой уж и сложный?
сложнее к примеру radius? или tacacs? или sip или h323? iax2?
почитайте rfc, там ничего сложного
за пару дней напишите если подойдете с умом

сомнительное удовольствие, ибо фиксить дохрена, еще не факт что работать в итоге будет

это как это не будет?
если дохрена - пишите свою реализацию
кил на 100 можно вложится

>а что вы считаете что диаметр такой уж и сложный?

ды нет, Base Protocol не такой уж и сложный, но от него толку не особо, а вот дальше уже интересней DCCA, NASREQ например. все это осложняется еще тем, что тестировать не на чем

> ды нет, Base Protocol не такой уж и сложный, но от него толку не особо, а вот дальше уже интересней DCCA, NASREQ например. все это осложняется еще тем, что тестировать не на чем

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

тогда странный вопрос, а нафига вам все это если в итоге и работать несчем будет?
если ни железки ни софта у вас в итоге нет

>тогда странный вопрос, а нафига вам все это если в итоге и работать несчем будет?

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

> работать есть с чем, но тестирование и отладку с реальной системой при разработке использовать не могу.

не вопрос, протокол сервер-клиент одинаковый в реализации class DIAMETER::TServerConenction и class DIAMETER::TClientConnection можно реализовать так же просто как и протокол разница мизер

вам останется только проверить правильность состыковки для этого дампите все возможные варианты pcap обмена у рабочего железа/софта и разобрав этот обмен описываете поведение в своих class DIAMETER::* и проверяете насколько он идентичный идея надеюсь поняли

>не вопрос, протокол сервер-клиент одинаковый в реализации

в этом есть определенный недостаток, трудно проверить правильность логики и корректность автоматов если и клиент и сервер делал ты сам))) где нить невнимательно прочитал rfc, не так понял и все, ошибка обнаружится на этапе внедрения.

насчет дампов тоже все непросто, у меня их нет, и мало вероятно что я их заимею.

кстати попутный вопрос, может кто знает где достать дампы реальных работающих систем? или может есть путевый diameter сервер для тестирования? я пока втречал только коммерческие варианты. есть еще реализация стека openblox, даже сервер удалось запустить, но пока пользы из этого не извлек

логику конечных автоматов можно посмотреть по красивым картинкам в wiki
в конце концов коллфлов обмен должен быть идентичным с оригианльным
при запросах или ответах(теструем отдельно серверный отдельно клиентский)

хотя вы сами себе противоречите
- система есть
- тестировать на ней никто не даст
- снять рабочие pcap никто не даст

зачем вам такое ТЗ?

есть еще реализация стека openblox, даже сервер удалось запустить, но пока пользы из этого не извлек

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

>вообщем типичный подход новичка, все боюсь но начальство приказало.

довольно странный вывод вы сделали. почему вы думаете что я чего то боюсь? у меня действительно сложные условия, железки у меня нет и не будет, а к той железке, где должно будет это работать никто не подпустит пока нет реализации, ибо коммерция, конфиденциальность и все такое. я вынужден работать в таких условиях, извращаться и искать пути решения. все что у меня есть, это дока по целевой системе с описанием implementation specific, причем не очень подробная.

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

>зачем вам такое ТЗ?

по вашему мне приносят ТЗ пачками, а я выбираю какое бы мне реализовать?

>хотя вы сами себе противоречите

да, система есть, но принадлежит она другим людям

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

я бы смело послал заказчика с такими условиями в ОПУ

либо подписывайте что то типа NDA и идите дампить pcap
железка с чем то работает?
значит софт с которым она работает можно поставить отдельно и отлаживать уже со своим софтом
корча из себя железку отладите в таком тандебе большинство глюков
так же можно будет сделать nc сокета и получать копии запросов от железки онлайн и смотреть как отрабатывает ваш софт и сравнивать с реальными ответами того софта
вообщем вариант милион с хвостиком
но думать вы не хотите
главный в таких ситуациях это разработчик тоесть вы
а у вас как раз на оборот, главный заказчик
того он вам не даст, туда не подпустит

>вообщем вариант милион с хвостиком

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