Форум: АВТОСПУТНИК - персональная навигация
Тема: Пробки
Страницы: 1 2 [3] 4 5 6 7 8 9
[Ответить]
pavel_ss [21.08.2007 13:38] :
поменял устройство на Xten X500+
пробки стали грузится без ошибки что данные не полностью загруженны
остается вопрос по прокладке маршрутов в обьезд пробок
Андрей К. [21.08.2007 23:23] :
Если бы СМИЛИНК разрешил опубликовать информацию о своём протоколе, вы бы долго смеялись. Это не HTTP, нормального контроля ошибок или чего-то подобного там нет.
Наши предложения (упаковать пакет в ZIP, модифицировать протокол, уменьшив его объём в 2 раза и т.д.) пока на стороне сервера реализовать не удалось.
Относительно повторения попыток. Можно сделать, но, как показывают наши тесты, очень часто не удаётся получить хвостик пакета много раз подряд.
Относительно объезда пробок. В обновлении эту "особенность" полечим.
AlchHiMyst [22.08.2007 13:46] :
Отвечу Как представитель СМИЛИНКА
Для тех кто интересуется поясню, как работает протокол СМИЛИНК по передаче пробок.
Выдержки из описания протокола:
"Для обмена данными между приложением и сервером используется протокол HTTP с дополнительной информацией в заголовках запросов и ответов. Клиент устанавливает соединение с сервером, передает запрос. Сервер выдает ответ и завершает соединение.
Общий алгоритм взаимодействия: клиент делает запрос авторизации, сервер создает в памяти виртуальную сессию (определяемую параметром *******), после чего клиент может делать запросы данных с интервалом не более 10 минут. Если в течение 10 минут клиент не сделал запрос на получение данных, то сервер считает такую сессию завершенной и для получения данных клиенту снова необходимо сначала сделать запрос авторизации, а потом – запрос на получение данных."
После успешной авторизации и запроса данных сервер передает 2000 байт с кодированными по специальному принципу данными. Причем насколько я понимаю если пакет пришел неполностью то во первых это очевидно - пришло менее 2000 байт, во вторых в момент преобразования и декодирования данных возникновение ошибок практически неизбежно. В результате программа будет показывать не пробки от СМИЛИНК а что называется "погоду на Марсе".
Что касается нашего сервера тайм аутов и проч.
Тайм-аут на установление соединения 60 сек либо 4096 попыток. Если поэтим условиям соединение не устанавливается - то сервер прекращает попытки. Если удалось нормально установить соединение и пройти авторизацию, то сервер держит соединение 10мин!!!!! Если в течении 10 мин. нет запросов сервер разрывает соединение.
Даже в случае какой-то чудовищной загрузки нашего сервер генерация пакета данных займет ну допустим несколько секунд, потом пакет передается стандартными сетевыми транспортами.
К тому - же я очень сомневаюсь что ГПРС настолько ненадежный что за 10 минут неможет без ошибок пропустить пакет из 2000 байт....
Почему-то ну ни разу не вижу в протоколе ничего смешного!
)Статусов в настоящий момент передается 4-ре:рабочее движение, затруднение, пробка и перекрытие движения.
И кроме статусов передается причины затруднений : 0 - скопление транспорта, 1 - дорожные работы, 2 - ДТП, 3- Перекрытия из-за Мероприятий.
Протокол с 432мя участками успешно работает на всех приложениях.
Проблемы с недоходом пакетов начались при расширении зоны покрытия СМИЛИНК и модернизации протокола передачи данных. В результате количество участков увеличилось с 432х до 810. Что в результате увеличило пакет данных с 874 до 2000 байт.
Протоколы написаны под нашу бесплатную программу СМИЛИНК. Причем пакеты на наши приложения принимаются через ГПРС нормально без сбоев и в полном объеме.
Оптимизировать протокол специально для Автоспутника нет возможности по целому ряду причин.
Что касается упаковки в пакет ZIP.....Архивировать 2000 БАЙТ данных!!! - "не смешите мои подковы" что называется. Служебные сообщения архиватора в результате могут увеличить объем данных, к тому-же это невозможно на данном этапе. !
В результате имеем то, что имеем. Пробки на Автоспутнике ГЛЮЧАТ.
Почему?? - НЕЗНАЮ и походу никто не знает, т.к. внятного ответа никто дать не может.
НавСис ссылается на кривоту нашего протокола без указания конкретных причин и предложений.
С нашей стороны вроде все работает, пакеты данных формируются и передаются, наши программы принимают информацию по ГПРС в полном объеме.
С другой стороны наши программисты серьезно загружены различными задачами и не могут досконально разбираться в особенностях приема нашего протокола Автоспутником.
И получается, что между 2х компаний, которые отбрыкиваются от проблемы – страдает пользователь.
Лично мне обидно и грустно, что пользователи программы Автоспутник не могут КАЧЕСТВЕННО воспользоваться нашей услугой и нашей информацией.
Мы стараемся улучшать качество нашей Услуги и качество предоставления наших услуг, но далеко не всегда все зависит только от нас.
Считаю, что вместо того чтобы сваливать вопрос на все возможные стороны, нужно взять и разобраться в чем конкретно проблема, чего не хватает и что мы можем сделать в сложившейся ситуации, чтобы решить проблему и пользователи стали довольны.
Со своей стороны могу обещать что сегодня запросим у НавСис`а их виденье проблемы и варианты решения, и если проблема кроется на нашей стороне и есть возможно ее устранить то примем меры к устранению данных ГЛЮКОВ.
Андрей К. [22.08.2007 23:46] :
Ок, раз такое дело, то приведу некоторые объяснения происходящего.
1. Клиент открывает сессию, после авторизации начинается передача файла. по протоколу мы можем только ждать. В какой-то момент передача прекращается. Мы узнаём, что файл пришёл неполностью, только по его размеру (никакого контроля ошибок в потоколе нет). Ок, снова запрашиваем файл. Он снова качается сначала, и опять не полностью.
Тесты через Bluetooth-GPRS (разные операторы) в условиях не идеального приёма дали средний результат потерь 18% данных. При этом, как показывает практика, долбиться "до победного" не получается, так как все пакеты приходят не полностью.
2. Что можно сделать на стороне клиента? Продолжать запросы, как я уже сказал, практически бессмысленно. В этом несложно убедиться, потестировав закачку вручную. Сейчас сделано на нашей стороне: обработка неполного пакета, тестовая консоль, вывод пробок при получении более 50% пакета. Возвращён из небытия старый протокол СМИЛИНК GPRS' . Там объём данных вдвое меньше, и проходит он лучше.
Кстати, сообщу специалистам СМИЛИНКа: кодирование данных в Вашем протоколе происходит последовательно, так что при приёме и декодировании частичного пакета получаем правильную (с точки зрения СМИЛИНКа) картину, но только на той части магистралей, которые попали в полученную часть файла. Никакой "погоды на марсе". Что пришло, то и показываем. Но НЕ ВСЁ.
3. Предложено СМИЛИНКу:
- уменьшить размер пакета. Сейчас протокол в основе бинарный, однако он зачем-то дополнительно кодируется в текст (наследие пейджингового Вессолинка?), что увеличивает объём данных вдвое. Отказавшись от текста, возвращаемся практически к старому объёму данных и к стабильной работе. Ответ: "Технически невозможно".
- уменьшить размер пакета, сжав его. Тесты показывают, что, опять таки, удаётся уменьшить размер пакета вдвое. Выяснилось, что прикрутить библиотеку архивации к серверу выдачи пробок тоже "технически невозможно", так как он написан на довольно странном для серверного приложения языке программирования, с которым специалисты СМИЛИНКа на "Вы".
- сделать туннель через сервер "Навигационных Систем", на котором реализовать нормальный протокол с контролем ошибок и докачкой. Позволит не заниматься препирательствами и глупыми объяснениями проблем с протоколами и сопряжениями, а дать нормальный сервис и обозначить ОТВЕТСТВЕННОГО, то есть нас. Окончательного ответа пока нет, однако, боюсь, он будет отрицательным "по соображениям безопасности и биллинга". Хотя какой биллинг - услуга ведь оплачивается повремённо...
К сожалению, только на стороне клиента проблема не решается, необходимы действия на стороне провайдера услуги.
Все необходимые объяснения СМИЛИНКу были даны, предложения по разруливанию ситуации сделаны. Объяснение, почему проблема не решается, кроется вот в этой фразе: "С другой стороны наши программисты серьезно загружены различными задачами и не могут досконально разбираться..."
Надеюсь, время досконально разобраться и сделать хотя бы что-то на стороне сервера всё же найдётся.
p.s. Мы можем отключить сообщение о неполной закачке пробок. И всё будет, как у других. Что пришло, то пришло...
p.p.s. А можем опубликовать детальное описание протокола, если СМИЛИНК не возражает. Программистам - юмористическое чтение на досуге
Андрей К. [22.08.2007 23:50] :
Да, кстати. Для улучшения результата рекомендую переключиться на канал "СМИЛИНК GPRS'" (штрих). Это старый протокол, там пакет меньше и доходит он лучше.
И приношу всем извинения за довольно странную и глупую, с моей точки зрения, ситуацию.
AlchHiMyst [23.08.2007 13:08] :
Прокомментирую по пунктам..
1) Мне странно то, что через ГПРС Автоспутник неполучает полностью пакеты а наше ПО получает пакеты в полном объеме.
2) Я не программист поэтому о всех тонкостях кодирования/декодирования и преобразований немогу сказать, за эту часть отвечают наши программисты которые разбираются в особенностях работы нашего протокола, и сами могут и сообщить и проконсультировать !
Если НавСису удается корректно отображать пробки на Автоспутнике по неполным данным, то это наверно хорошо.
Очень хорошо что сейчас стало понятно что означает магический и нигде незадокументированный протокол СМИЛИНК с штрихом на Автоспутнике.!
3) что касается нашего протокола его оптимальности/неоптимальности и т.д. есть несколько моментов - можно долго препираться что-где как но есть несколько обстоятельств:
а) протокол через ГПРС работает как минимум на наших программах
б) Модернизация протокола осложняется во-первых первых несамой удачной средой разработки в которой протокол был реализован изначально и во вторых тем что принято решение о разработке принципиально другой платформы по предоставлению данных. Не готов говорить о сроках но модернизировать старый протокол сейчас просто не целесообразно. Изменения могут быть внесены только для того чтобы исправить ошибки.
в) Модифицировать протокол непосредственно под Автоспутник - тоже не уверен насколько это целесообразно, особенно если в других приложениях это работает.
Так-что фразу "Технически невозможно" нужно читать как нецелесообразно!
Что касается предложения организовать "тоннель" предложение поступило только вчера, спасибо Андрею за идею, мы обязательно проработаем вопрос и в данном направлении.
Что касается наших программистов то действительно загруженность большая и ресурсов нехватает - впрочем я этого и нескрываю.
Мы делаем все что можем в данной ситуации и это одна из причин по которой лично я вижу нецелесообразным переделывать и подгонять работающий на другом ПО протокол под Автоспутник. Но если выяснится, что действительно проблема на нашей стороне, тогда мы изыщим ресурсы на решение вопроса.
Да... ситуация действительно странная..
Я очень расчитываю, что, совместно с Андреем, мы сможем в ближайшее время, решить данную проблему, и информировать пользователей о улучшении нашего сервиса.
P.S. Детальное описание нашего протокола, по понятным причинам, является закрытой информацией!
P.P.S. Ту Андрей - предлагаю перенести дальнейшее обсуждение вопросов по техническому решению данного вопроса в почту, так будет намного эффективней, да и небудем грузить пользователей!
McHarny [23.08.2007 17:13] :
- AlchHiMyst писал(а):
P.P.S. Ту Андрей - предлагаю перенести дальнейшее обсуждение вопросов по техническому решению данного вопроса в почту, так будет намного эффективней, да и небудем грузить пользователей!
boeing741 [23.08.2007 23:28] :
Да. Согласен. Переносить беседу не надо. Я лично с удовольствием буду читать и поддерживать её.
kostya_10 [24.08.2007 00:55] :
Я конечно точно не знаю, но мне кажется, что большенство подпищеков услуги "Свободные дороги" являются пользователи ПДЖС ПРО и Автоспутника.
И мое мнение:
Смилинку надо изыскать ресурсы для решения проблемы, а то рискуете потерять очень много клиентов.
НавСиму тоже надо над этим работать очень усиленно, т.к Ваша программа держится в лидерах на рынке только благодаря этой услуге.
PS. Читаю этот форум и диву даюсь, как у нас видут бизнес.
Andry_Civic [28.08.2007 01:21] :
да уш
[Ответить]
[< Назад] [Вперед >]