WITS/WITSML

[Prepodobie]

У энержестикс появился специальный протокол для witsml - etp

[amt]

XML это неплохо для небольших объемов данных, особенно если стандарт хорошо описан. На практике же объемы большие, а режимы докачки данных, параллельной передачи данных, слияния данных, промежуточного кэширования и т.п. этим форматом не оговариваются. Т.е. надо делать и форматы и протоколы вариативные, гибкие (допускающие неконфликтные расширения), поддерживающие двусторонний обмен в реальном времени и так далее. Опять же уже сказали, что их технологии бурения и наши не на 100% подходят и нужно как минимум подмножество стандарта типа WITSML-RU, учитывающее эти особенности.

Надо четко разделять  формат данных от транспортировки данных.
Есть несколько надежных (без чего бессмысленно) систем гарантированной транспортировки данных (у IBM, например). Можно пользоваться ими. Можно написать свою. Но это не имеет отношения к формату представления или хранения.

[amt]

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

Буквально недавно приезжали одни заказчики и спрашивали насчет подключения ЗТС. Я сказал что проблема может быть при дисконнекте, могут быть потери данных, а докачки данных при текущем протоколе не предусмотрено. Они очень удивились и подумали что это у нас недоработка, я им попытался объяснить что это принцип WITS протокола. Т.е. на текущий момент эти WITS протоколы это архаичные костыли. Было бы очень не плохо разработать современный и универсальный протокол (на базе json, меньше перерасхода чем у xml). Где бы можно было бы учесть и докачку и запрос только нужных параметров.

Вам нужен стандарт или обсуждение преимуществ/недостатков и предложение чего нового?
Обсуждать можно здесь.
Стандарт требует официоза, тусования на предмет, кого допустить до чего и кто возглавит. Финансирования. Потом еще много официоза. Потом стандарт переведут в разряд рекомендованных и забудут.

json примитивнее xml - он не расчитан на рост потребностей.
и вообще - есть огромное количество других представлений. Я, вот, таким пользуюсь - http://ru.ecomstation.ru/showarticle.php?id=219

[PDS]

Вам нужен стандарт или обсуждение преимуществ/недостатков и предложение чего нового?
Обсуждать можно здесь.
Стандарт требует официоза, тусования на предмет, кого допустить до чего и кто возглавит. Финансирования. Потом еще много официоза. Потом стандарт переведут в разряд рекомендованных и забудут.

Стандарт нужен, но у нас его не будет. До тусовок дело не дойдет, нет финансирования.

json примитивнее xml - он не расчитан на рост потребностей.
и вообще - есть огромное количество других представлений. Я, вот, таким пользуюсь - http://ru.ecomstation.ru/showarticle.php?id=219

json и xml - это по сути конкуренты, мало того, уже макрософт переводит некоторые вещи на json. Он рассчитан и на рост и на развитие. Другие есть, но зачем использовать не распространенные форматы, когда тот же json реализован в куче различных библиотек.

[amt]

json и xml - это по сути конкуренты, мало того, уже макрософт переводит некоторые вещи на json. Он рассчитан и на рост и на развитие. Другие есть, но зачем использовать не распространенные форматы, когда тот же json реализован в куче различных библиотек.

JavaScript становится все популярнее и популярнее. Это он конкурент всему, а не части его.
Мелкомягкие 1. так часто лажали с определением перспективных технологий, что совсем не могут быть авторитеом и 2. их интерес к новшествам всегда имеет целью подмять и лицензировать, как они сейчас проделывают с линуксом.
Но это все неважно. Ибо не с того конца.

[PDS]

json и xml - это по сути конкуренты, мало того, уже макрософт переводит некоторые вещи на json. Он рассчитан и на рост и на развитие. Другие есть, но зачем использовать не распространенные форматы, когда тот же json реализован в куче различных библиотек.

JavaScript становится все популярнее и популярнее. Это он конкурент всему, а не части его.
Мелкомягкие 1. так часто лажали с определением перспективных технологий, что совсем не могут быть авторитеом и 2. их интерес к новшествам всегда имеет целью подмять и лицензировать, как они сейчас проделывают с линуксом.
Но это все неважно. Ибо не с того конца.

json - это формат данных, а JavaScript - язык программирования. Формат данных не может быть частью языка программирования. Просто этот формат изначально пошел из программ на JavaScript. Но на данный момент json имеет огромную поддержку со стороны разработчиков. Куча парсеров на любом языке программирования.

[REA]

Стандарты приходят и уходят. XML еще какое то время проживет. Он удобен тем, что для него уже парсеры понаписаны, но неудобен тем, что парсинг медленный и большие объемы не передать. Ну и возможность ошибки при записи и чтении тоже велика, если не использовать автоматизирование преобразование схемы.

[DenisA]

Доброго времени суток.
Нет ли у кого описание формата WITS level 2b (level 1 - 2b). Что-то ни где не могу найти. Описание на http://home.sprynet.com/~carob/ как-то маловато для понимания.

[Serg_sd]

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

[Serg_sd]

Выкладываю простейший витс сервер с исходным кодом . Может он не многое , отправляет по витс текущее время и вес на крюке сгенерированный случайным образом. Работает на порту 10000. Прошу протестируйте на своих приемниках кому не лениво.

[PDS]

Выкладываю простейший витс сервер с исходным кодом . Может он не многое , отправляет по витс текущее время и вес на крюке сгенерированный случайным образом. Работает на порту 10000. Прошу протестируйте на своих приемниках кому не лениво.

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

[Serg_sd]

Какие ошибки вы там нашли? Расскажите пожалуйста.

[PDS]

Какие ошибки вы там нашли? Расскажите пожалуйста.

1. Нельзя передавать адрес локлаьной переменной в другой поток, одновременно используя эту переменную в основном. Мало того что проблема синхронизации доступа, так еще и измениться может до того, как новый поток ее к себе скопирует.
2. Все новые потоки используют один буффер для формирования WITS данных.
3. Отправлять данные нужно размером не всего буффера, а только столько, сколько туда положил, иначе придет мусор.

Это я еще не говорю о совершенной ненужности использовать многопоточность для такого простого сервера.

[Serg_sd]

1. Про какую переменную идет речь я не понял , можете назвать.
2. Тут спорить не буду для полноценного сервера надо наверно так делать,  в моем случае думаю не критично.
3. Данные интерпретируются приемником как строка, а строка заканчивается 0 либо !! если wits остальное отсекается. 
Без многопоточности думаю никак , каждому клиенту по потоку для обслуживания.

Программа тестировалась на стандартном приемнике , данные принимал графики отрисовывал. Более одно клиента подключать правда не пробовали. Проверить нужно было будет принимать или нет.

[PDS]

1. Про какую переменную идет речь я не понял , можете назвать.

Хендл входящего коннекта, который передается по адресу в другой поток. Имя уже не помню.

2. Тут спорить не буду для полноценного сервера надо наверно так делать,  в моем случае думаю не критично.

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

3. Данные интерпретируются приемником как строка, а строка заканчивается 0 либо !! если wits остальное отсекается. 

Отлично, 80% гоняете по сокетам мусор не нужный. Плюс если сделаете сервер правильным, а правильный сервер после каждой отправки данных не разрывает соединение, то у вас будет перемешка данных и мусора, и что тогда будете отсекать?

Без многопоточности думаю никак , каждому клиенту по потоку для обслуживания.

Что значит думаю? Тут потоки как собаке пятая нога, это просто аксиома.