XML через UDP

[cy6erGn0m]

Заказчик заказчика сотворил целый протокол обмена данными, который подразумевает обмен данными по UDP. Насколько безумна эта идея? И как вообще такое парсить? Я вот сделал простенький фильтр чтобы отлавливать мусор, который потенциально может получаться при потере данных\дублировании\неверном порядке, но тем не менее остаётся масса возможностей при которых повреждённые данные проскочат. Что делать? Неужели у такой идеи как XML через UDP вообще может быть оправдание?

[drBatty]

Неужели у такой идеи как XML через UDP вообще может быть оправдание?

вы про этот язык XML? http://www.citforum.ru/internet/xml/index.shtml
а что такого? по UDP можно и AVI передать при желании.. разве сложно повесить на каждую датаграмму порядковый номер? вот только зачем?

[cy6erGn0m]

Да нет никакого порядкового номер у датаграммы. В датаграммах лежат просто xml документы. XML очень нежный по своей сущности. А тут полный букет радостей: потеря частей, возможное дублирование, неверный порядок следования и т.п.

[rm_]

Разве дублирование или повреждение возможны?
Вроде бы могут быть только две проблемы:
- потеря датаграммы целиком
- изменение порядка датаграмм
Если XML док-ты совсем небольшие и целиком помещаются в датаграмму, осталось добавить внутрь них порядковый номер (либо более обще, уникальный идентификатор).
Если большие и не помещаются, но при этом обязательно хочется UDP, тогда придётся изобретать поверх UDP, на уровне приложения, свой собственный мини-аналог TCP

[cy6erGn0m]

Дублирование возможно. Под повреждением я имел ввиду то, что при чтении данных как из потока данные могут выглядеть битыми из-за неверного порядка или потерь.
Вот в том то и дело что ничего нельзя сделать. Протокол уже был сделан и выдан мне в виде спеки, типа "пользуйся" на здоровье. Надо же попасть так было с этим UDP.
Что касается размеров, то думаю в обычной ситуации данные должны помещаться целиком.
Кстати, действительно, может стоит читать их из сокета как отдельные пакеты, а не как поток?
Просто проблема в том что хотя сооружение вроде работает, но это "в пробирке". Если присмотреться, то очевидно что всё это ненадёжно очень. Ей богу, "в бою" эта штука отвалится.

[drBatty]

Вот в том то и дело что ничего нельзя сделать. Протокол уже был сделан и выдан мне в виде спеки, типа "пользуйся" на здоровье. Надо же попасть так было с этим UDP.
Что касается размеров, то думаю в обычной ситуации данные должны помещаться целиком.
Кстати, действительно, может стоит читать их из сокета как отдельные пакеты, а не как поток?
Просто проблема в том что хотя сооружение вроде работает, но это "в пробирке". Если присмотреться, то очевидно что всё это ненадёжно очень. Ей богу, "в бою" эта штука отвалится.

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

[rm_]

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

Кстати, действительно, может стоит читать их из сокета как отдельные пакеты, а не как поток?

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

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

[Denjs]

Неужели у такой идеи как XML через UDP вообще может быть оправдание?

вы про этот язык XML? http://www.citforum.ru/internet/xml/index.shtml
а что такого? по UDP можно и AVI передать при желании.. разве сложно повесить на каждую датаграмму порядковый номер? вот только зачем?

и как только вы повесите на него порядковый номер .. вы получите ЧТО? прааавильно. TCP.
а зачем козе боян? лучше нормально сделать по TCP)

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

Со ссылкой на спецификации, что UDP не гарантирует доставку данных, и никак не проверяет дошли данные или нет.

Если большие и не помещаются, но при этом обязательно хочется UDP, тогда придётся изобретать поверх UDP, на уровне приложения, свой собственный мини-аналог TCP

вот-вот. )

________________________________________
оправдание у идеи использовать UDP для большого объема данных - может быть только одно, как я понимаю, - неопытность разработчика. или желание сотворить на коленке "что бы только отвязались".
Затребуй исходники, надеюсь ты сможешь сделать из этого TCP.
Возможно тебе удастся объяснить, что такая переработка займет меньше времени, чем лечение букета болезней следующих от "потеря датаграммы целиком и изменение порядка датаграмм". если не поверят - напиши хоть электронное письмо, разъсни ситуацию и предмет болезней которые из этого следуют, предложи переделать для TCP и т.д. - все с копий начальнику и начальнику твоего начальника. Что бы зафиксировать твой крик о безумстве такого шага, и что-бы когда "это" перестанет работать - на тебя не смогли повесить всех собак. Если тебя заставляют делать гавно - прикрывай задницу.

[drBatty]

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

почему только до 2х? можно в каждом пакете посылать id
я думаю что XML может быть любого размера, и запихать любой XML в 1 пакет невозможно(ИМХО. Надо эту спецификацию смотреть.)
и 1 в 2пакета тоже.

и как только вы повесите на него порядковый номер .. вы получите ЧТО? прааавильно. TCP.
а зачем козе боян? лучше нормально сделать по TCP)

откуда я знаю? ИМХО это будет не TCP, а TCP поверх UDP. Может в этом есть плюсы - если передающая сторона включилась, покидала датаграмм, и отключилась. А приёмные сидят и ждут.

Со ссылкой на спецификации, что UDP не гарантирует доставку данных, и никак не проверяет дошли данные или нет.

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

[rm_]

почему только до 2х? можно в каждом пакете посылать id

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

[cy6erGn0m]

Не просто проблематично. Это просто невозможно. Протокол принят и одобрен так сказать. он не предусматривает какую бы то ни было нумерацию пакетов. Расписаны только условия когда и какие документы приходят, когда какие должны быть широковещательными, а какие нет. Изменять протокол нельзя. К тому же всё это - комплекс embedded устройств, разные части делаются в разных организациях как я понимаю. Исходники никто не даст. Спеку и ту дали только урезанную, а именно только то, что необходимо нашей стороне. К сожалению, про условие "в каждой датаграмме только целое число документов" ничего не сказано. Я не вижу гарантированного решения задачи в таком случае.. так что пусть получат своё. Я сделал всё что мог и совесть моя чиста. Если документы не будут дробить на части, то всё будет отлично работать, если будут, то опасны на самом деле только случаи, такие как этот

<?xml version=....><root-element>|<element1>very important data</element1>|</root-element>

где | - граница пакетов. Если, например, потеряется второй пакет с element1, то придёт <?xml version...><root-element></root-element> и у меня не будет повода отсеять такое и я пропущу это дальше в SAX-парсер и будь что будет.
Если документ будет откровенно кривой или что-то перепутается, то это я уже и так отсеиваю. Так что задача частично решена. А полного решения думаю нет.

[drBatty]

А полного решения думаю нет.

почему нельзя передать датаграмму с набором контрольных сумм?
тот кто примет просто проверит сумму и составит датаграммы в нужном порядке. и будет уверен что все пойманы, причём без ошибок.
и это будет UDP, а не TCP.

[cy6erGn0m]

Да потому что я не контролирую ни одну из частей этой системы. Я почти всегда только принимаю. Я не контролирую протокол и не могу его менять. В моём распоряжении только мой код.



Моя бы воля, я бы просто сделал tcp и всё - это и было бы самым надёжным решением. Однако, приходится иметь то, что имею.


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

[drBatty]

Да потому что я не контролирую ни одну из частей этой системы. Я почти всегда только принимаю. Я не контролирую протокол и не могу его менять. В моём распоряжении только мой код.

мда.. склеить произвольно порезанный XML видимо нельзя... в общем случае...