GPS тракер в реално време през GSM мрежа

dido написа:

lz1fw написа:

Ако тракера е в място с лошо, ама не абсолютно никакво покритие, това е проблем. Данните заминават към сървъра, устройството ги отчита за предадени и не ги запомня, а сървъра не успява да приеме нищо. Тези моменти при лошо покритие още ги изследвам, но нещата изглеждат да са така. Точки се губят не при никакво, а при някакво, но лошо покритие.

Пропуснах това - малко ми е мътно как се получава описания ефект.

Ако ползваш http POST, при успех на заявката сървърът съвсем стандартно би трябвало да ти отговори с 200, 201 или 202. Друг отговор или липсата на отговор в някакво приемливо време - примерно 20 сек, можеш да приемеш за счупено предаване и да пробваш пак.

По принцип това ми е ясно. Обаче програмата в Андроид часта е правена от друг и все още нямам идея как и на какво реагира. В .PHP частта на сървъра не съм се задълбавал все още. Направил съм го да работи как да е. Интересното е, че работи учудващо добре. Smile

Ще огледам всичко, когато му дойде реда.

Колега lz1fw,
в програмата "ViewRanger"/Android, Ios/ има функция "BuddyBeacon", цитат:
"BuddyBeacon is a unique feature in the ViewRanger app that allows you to share your real-time location with friends and family while you’re out hiking.
ViewRanger uses the GPS chip in your phone to pinpoint your precise GPS location, and BuddyBeacon allows you to transmit those coordinates to anyone with permission to follow you via the app.
We’ve designed it so anyone heading out into remote locations can let people know exactly where they’re going, allowing you to share your adventures while also providing important information about your position in the case of emergency.
BuddyBeacon is used by hikers, cyclists, trail runners and explorers all over the world. It has also become a crucial piece of technology for Search and Rescue teams, who use it to coordinate team members during emergency call-outs."
За спасителни операции прехвърлянето на данни по GSM е възможно при градски условия, но по планините е неприемливо поради ниската степен на сигурно покритие, видя какво се получи с твоя опит в Рила. Остава възможността за използване на мобилен Интернет, не че сега е нещо по сигурно, но има бъдеще, идва Starlink.
lz1ksf vy 73!

Чакай малко Smile

Хич не съм сигурен в “ниската степен на сигурно покритие". Във всеки случай точно това, което съм публикувал за Рила, сочи точно обратното. В района на Страшното езеро тракерите се държаха перфекно... или поне приемливо за целите на евентуално търсене и спасяване.

Разкъсването на траковете е друга бира. Не съм го спестил, защото това е реалността. Ама това не прави нещата невъзможни при правилен подход.

Та какво видя ти в разказаното за Рила, че нещо мненията ни се разминават.

	lz1fw написа:
	Леле, откога ст. н. с. стана обидно?

Ами старомоден недоучил старец от Българската Академия на Нищонеправенето си е обида. Laughing

Цитат:

... в зона на пълна липса на GSM покритие данните не се губят, а се запомнят от устройството и се предават в момента, в който GSM обхвата се появи. ... Ако тракера е в място с лошо, ама не абсолютно никакво покритие, това е проблем. Данните заминават към сървъра, устройството ги отчита за предадени и не ги запомня, а сървъра не успява да приеме нищо.

Това прилича на протокол, при който тракера не очаква потвърждение от сървъра за приемане на данните.

Николай_K написа:

lz1fw написа:

... в зона на пълна липса на GSM покритие данните не се губят, а се запомнят от устройството и се предават в момента, в който GSM обхвата се появи. ... Ако тракера е в място с лошо, ама не абсолютно никакво покритие, това е проблем. Данните заминават към сървъра, устройството ги отчита за предадени и не ги запомня, а сървъра не успява да приеме нищо.

Това прилича на протокол, при който тракера не очаква потвърждение от сървъра за приемане на данните.

До тук е ясно, че протоколът е от HTTP фамилия.

Доста вероятно е и аз да не съм конфигурирал предаващата програма правилно... или пък приемащата... не искам да гадая каква в причината.

Загубата на данни е факт. И сега изненада: не ме дразни, напротив служи ми за храна на моите фантазиите при търсене на решения. Споменавал ли съм, че съзнателно търся изключения и рядко срещани проблеми? Ако ги няма си ги създавам - затова например търкалям десетки символи между тракера и сървъра. Присъствал ли си на истински изпитания? Там слагат изделието в една камера и го греят, изтудяват, обливат с вода и пара, друсат го и изобщо се държат ужасно с него. Аз камера нямам, но си я моделирам. Smile

Нещо като вица за онзи дето мъкнал релса през пустинята. Като се наиграя ще хвърля релсата. Smile

Имах предвид протокола на приложно ниво. Би трябвало приложението в телефона да изпрати пакет с данни, да изчака потвърждение от сървъра, че пакета е приет и едва след това да предава следващ пакет.
Използване на http тип транспортен протокол е несериозно. Става само за твоите експерименти.

Николай_K написа:

Имах предвид протокола на приложно ниво. Би трябвало приложението в телефона да изпрати пакет с данни, да изчака потвърждение от сървъра, че пакета е приет и едва след това да предава следващ пакет.
Използване на http тип транспортен протокол е несериозно. Става само за твоите експерименти.

Може да е несериозно, но СТАВА.
Very Happy

между другото
https://en.wikipedia.org/wiki/OSI_model
Very Happy

	Николай_K написа:
	Ами старомоден недоучил старец от Българската Академия на Нищонеправенето си е обида.

Хм, съпругата ми, която някога беше ст.н.с. в БАН, би могла и да се засегне от такова определение. А пък аз, не само като бивш н.с. също там, бих я разбрал. Така че -- мерете си приказките, дори когато се шегувате. Old

	Николай_K написа:
	Използване на http тип транспортен протокол е несериозно. Става само за твоите експерименти.

Горното твърдение е твърде категорично и би могло да създаде впечатление за неинформираност и/или пристрастност. Основата причина да го споменавам, обаче, е, че то би могло да бъде и подвеждащо за читателите. По принцип всяко средство си има област на приложение със съответни предимства и недостатъци, оценката на които би трябвало да бъде предмет на подробен анализ, който да послужи при определянето на най-добрия подход в даден случай.

_________________
"Caminante son tus huellas el camino y nada más;
caminante, no hay camino, se hace camino al andar." -- Antonio Machado

[quote="Николай_K"]............. ст. н. с............

	Цитат:
	................

Все едно да кажеш: "Всички комунисти са маскари!"
Или: " Който не скача е червен!"
И др. под.

Естествено, че не всички комунисти са маскари, не всички пътни полицаи са корумпирани, не всички лекари точат Здравната каса, не всички учени са академични старчета, ..., но когато една професионална общност със свои организационни структури и съответните органи за управление на тези структури, атестационни комисии, ... дори ресорно министерство, допуска "маскари" в средите си и това е публична тайна, тогава проблемът е в самата общност.

Цитат:

Горното твърдение е твърде категорично и би могло да създаде впечатление за неинформираност и/или пристрастност. Основата причина да го споменавам, обаче, е, че то би могло да бъде и подвеждащо за читателите. По принцип всяко средство си има област на приложение със съответни предимства и недостатъци, оценката на които би трябвало да бъде предмет на подробен анализ, който да послужи при определянето на най-добрия подход в даден случай.

Пробвал съм предаване на данни с http рикуест. Става, но се предават твърде много излишни байтове, които са неизбежна част от http протокола.
Използвал съм трансфер на данни като .kml файл към ftp сървър. Става, но не е за онлайн предаване на данни.
Дълго време използвах предаване на данни към TCP сървър. Поради особености на GSM/GPRS, този протокол не е най-подходящия, въпреки, че масово се използва от GPS/GPRS тракерите.
Сега използвам UDP и (за сега) не срещам проблеми, а трафика (при същия обем данни) е осезаемо по-малък.
Говорим за TCP/IP през GPRS, а не през Ethernet или WiFi.

	Николай_K написа:
	Сега използвам UDP и (за сега) не срещам проблеми, а трафика (при същия обем данни) е осезаемо по-малък.

Ясно е, че общият обем данни би бил по-малък при пренос през UDP и също така е ясно, че този протокол не осигурява надеждно доставяне. Ако надеждното доставяне е изискване и се работи върху UDP би се наложила проверка на доставянето на по-горни нива, което не е непременно за предпочитане и също би увеличило обема и продължителността на комуникациите. Отделно от това съществуват проблемите със сигурността, по-конкретно удостоверяването на източника на данните, както и на липсата на изменения в тях при транспортирането им. Вие как решавате този кръг проблеми? Питам защото съществуват добри индустриални практики в това отношение, включително, например, стъпващи върху HTTPS.

_________________
"Caminante son tus huellas el camino y nada más;
caminante, no hay camino, se hace camino al andar." -- Antonio Machado

	Николай_K написа:
	Пробвал съм предаване на данни с http рикуест. Става, но се предават твърде много излишни байтове, които са неизбежна част от http протокола.

Колко повече е твърде много? По http може да се предаде съвсем тънка заявка, особено ако данните за пренос са да речем, няколкостотин байта. Изборът на http освен това все по-често се диктува не от способностите на линията, а от свойствата на приемника, който за IOT-джаджи обикновено е стандартен Web-сървър.

TCP транспорта долу от своя страна може да се окаже много по-приказлив в зашумена среда, но това е цената на reliability-то. Не вярвам, че ако решиш да играеш reliable пренос с UDP транспорт, ще си по-икономичен от TCP.

Транспорта въобще трябва се избира не догматично, а според нуждата от reliability на преноса в конкретната задача. Ако няма такава нужда и можем да жертваме данни - имаме под ръка UDP. Обратното - ползваме TCP.

_________________
Бутам след осмата бира Very Happy

Най-напред да уточним (още веднъж) някои важни подробности:
1. Коментираме предаване на данни от GPS тракер, а не данни за банкови сметки и достъпа до тях.
2. Тракерът използва 2.5G ембедед GSM модем с неговите възможности и АТ-команди, които зависят от производителя, т.е. от версията на фърмуера.
3. Връзката със сървъра е през 2.5G GSM мрежа с нейните особености, в това число в зависимост от оператора.

TCP протокола осигурява надеждно доставяне дотолкова, че при предаване на пакет и изтичане на таймаута без отговор, предава пакета отново. Ако отново не получи отговор, затваря сокета. При надеждна връзка, това е достатъчно. При лоша връзка, това увеличава трафика, още повече, че овърхеда на TCP е по-голям от този на UDP, а в случая данните за една локация са около 20 байта, което е по-малко от овърхеда на TCP пакета. Въпреки "надеждността" на TCP, има тракери, при които все пак има потвърждение на всеки пакет на по-горното ниво. Вижте протоколите на Teltonika, например. Другата неприятност на TCP е, че при липса на трафик, след няколко минути оператора хлопва сокета, а следващото му отваряне се таксува 1КВ, независимо, че ще се предават само няколко десетки байта. Не всички GPS тракери предават онлайн. Трета неприятност на TCP е, че лесно може да бъде флуднат (SYN, SYN, SYN, ...), което налага да се държи сметка за броя на конекциите и техните таймаути при отваряне на конекцията.

Аз използвам UDP с потвърждение на горното ниво, което дава възможност за емулиране на TCP, но адаптивно в зависимост от ситуацията. Например, повторно предаване на непотвърден пакет се прави само при ниво на сигнала над -100dBm. При UDP няма конекция и оператора не затваря сокета, но след известен таймаут отнема IP-адреса и/или порта, което означава, че следващ пакет ще дойде на сървъра от друг IP-адреса и/или порт. Това налага във всеки пакет да фигурира индивидуалния идентификатор на тракера.

За да бъдат изменени данните при предаване, трябва някой да има възможност за такъв достъп до мрежата на провайдъра, че да може да прихваща пакетите, изменя съдържанието, коригира чексумата и отново да ги предаде към получателя. Не, че е невъзможно, но защо да го прави? Още повече, че произволно изменение на един или повече байтове в пакета ще доведе до неговото отхвърляне при декодиране и вмешателството лесно се хваща. Дори да разполага с протокола, описващ данните в пакета, пак не може кой знае какво да промени - драстични промени на дата, час, координати, височина, скорост и посока на движение се хващат лесно.

Според написаното тук - http://planina.e-psylon.net/viewtopic.php?p=129124#129124 , lz1fw е променил задачата.

_________________
Бутам след осмата бира Very Happy

	Николай_K написа:
	...Коментираме предаване на данни от GPS тракер, а не данни за банкови сметки и достъпа до тях...

Ако от проследяващото устройство зависи нечий живот, точността и надеждността на предаваните от него данни може да е по-съществена от тази при боравене с банкови сметки.

Николай_K написа:

За да бъдат изменени данните при предаване, трябва някой да има възможност за такъв достъп до мрежата на провайдъра, че да може да прихваща пакетите, изменя съдържанието, коригира чексумата и отново да ги предаде към получателя. Не, че е невъзможно, но защо да го прави?

Не е непременно необходимо злосторниците да разполагат с достъп до мрежата на доставчика на свързаност или дори до който и да е физически участък от връзката до сървъра, който приема данните. Разнообразието от възможни MITM атаки предлага и много други възможности.

	Николай_K написа:
	Дори да разполага с протокола, описващ данните в пакета, пак не може кой знае какво да промени - драстични промени на дата, час, координати, височина, скорост и посока на движение се хващат лесно.

"Security by obscurity" би могла да бъде един от защитните слоеве, но да се разчита само на един такъв слой би могло да се окаже твърде лекомислено. Възможно е да бъдат приложени и промени, които са по-трудно забележими и затрудняващи достоверното проследяване. Освен това носачът на проследяващото устройство би могъл да желае да споделя данни за местоположението си в шифриран вид само с избрани от него получатели, но не и с други заинтересовани или дори целия свят...

_________________
"Caminante son tus huellas el camino y nada más;
caminante, no hay camino, se hace camino al andar." -- Antonio Machado