Колеги, налага ми се да организирам комуникация между компютър (сървър) и едно устройство с линукс. До сега нещата ставаха с предаване на XML текст през сокета, но се оказа, че устройството не е достатъчно бързо да обработва всичките щуротий и сега трябва да ползвам нещо "просто" - да организирам някакви рамки (пакети) и полета в тях, за да предам командите с данните. Мастер-а е сървъра, а устройството - подчинения. Някой има ли опит с такъв обмен? Трябва ми нещо, което е проверено, че работи - в смисъл като организация и справяне с евентуални грешки.

Хич не се разбира какво искаш.
XML парсера ли ти се бави или нещо друго?
Каква "рамка" очакваш? С един XML можеш да опишеш много неща и не вярвам да има някой дето да ти отговори твърдо и решително - "ей тъй става..". Справяне с грешки? TCP-то не ти ли стига?
До сега като си карал на XML кой се е справял с грешките?
Направи си един тест м/у XML и JSON парсер на лункското у-во и виж дали няма да е по - бързо и да те удволетвори. Все пак с JSON-а можеш да опишеш най различни структури от данни.

Какво е това устройство дето търкаля линукс, а на XML се бави?

Има нещо гнило тука... освен XML-а да е голям (мегабайти?), ама то ако данните са много обработката винаги ще е бавна.
Ние работим с XML-и, но нямаме проблем със скоростта, въпреки че хардуерът е доста слаб. По-скоро проблем ни е паметта и заради това трябваше да си правим сами парсването и валидирането без да ползваме рекурсивни алгоритми...

Пробвай с http://en.wikipedia.org/wiki/Binary_XML или някой друг двоичен йерархичен стандарт. Щото явно ти трябва йерархия. Ако не ти трябва - въпроса е излишен.

За кратки съобщения няма проблеми, но в случая се предават артикули с разни атрибути(име, цена и др.), които са много - примерно при 8000 артикула един по един и чакане на отговор дали е записан в базата данни на устройството. Всичкото отнема от порядъка на 20 минути и повече. Използвам Qt. За един артикул времето е около 100ms само обработката на XML-a.

значи пращаш по един XML за всеки артикул?
В такъв случай 100ms е страшно много време, нещо не е както трябва
При не много сложна дефиниция, валидирането и парсване до обекти (от типа на STL) трябва да е поне 1MB/s. Нямам представа как работят Qt библиотеките, но в общия случай най-тежкото в алгоритмите е заемането на памет. Средно на 5-10 байта се прави malloc(), тъй че един отделен пул може доста да ускори нещата.
Другото е какво правиш с данните, евентуално записването може да се бави, но това пък няма нищо общо с XML-а.

При всички случаи те съветвам да не бягаш от XML-a. Той си се налага като стандарт за тоя сорт приложения. Ако трябва си пренапиши парсера, или поне виж как да го оптимизираш вместо да измисляш нови формати...

Кой от всичките ХМЛ парсери на кют ползваш?
Да не си се метнал на xpath?

Използвам QXmlStreamReader - чрез него съм си направил прост парсер. Като гледах днес вероятно повечето време се губи от копиране на данните от едно място на друго. Примерно QTcpSocket->readAll() връща QByteArray, който трябва да го преобразувам на QString, за да пратя към QXmlStreamReader. Данните, които не са числа са кодирани base64 и трябва да ги предам към функцията, която декодира и тн. Най-големият проблем е и картинката, която пращам (също кодирана base64) с размер 40-60kB.

Не го преобразувай до QString. На QXmlStreamReader конструктура приема и QByteArray.

Конструктора да, но в случая QXmlStreamReader::addData(String&) си иска само QString

Ми не викай addData. След като си създал класа и си му задал референция към QByteArray не е нужно да викаш addData.

Мерси michev, въпреки, че не тръгва както би трябвало да е, т.е. да му задам девайс и да си чете от там. Ползвам пак addData(), но видях, че можело да се подава const char* указател. Процесорът е ARMG45 на 400MHz. Като цяло пак е бавно, но малко по-бързо от преди.