Tolka oregelbunden data - Klient och Server
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Tolka oregelbunden data - Klient och Server
Det man brukar(?) göra är ju att skapa en sträng, skicka strängen, ta emot strängen och slutligen tolka strängen. Visst, lite overhead men vadå?
Re: Tolka oregelbunden data - Klient och Server
En sträng? Är inte det lite "nybörjarfasoner"? Jag har testat det förut och det har alltid fungerat. Men det kändes som en B metod. Sträng......lillahuset skrev:Det man brukar(?) göra är ju att skapa en sträng, skicka strängen, ta emot strängen och slutligen tolka strängen. Visst, lite overhead men vadå?
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Tolka oregelbunden data - Klient och Server
Al: Tja, jag har programmerat för försörjning i snart fyrtio år och har lärt mig att strängar brukar vara väldigt användbara.
Hur brukar du lösa "big endian" och "little endian" i binära dataströmmar? Med strängar blir det trivialt.
Hur debuggar du binärdata på väg mellan två system? Jo du använder något verktyg som kan tolka protokollet. Inget konstigt.
Debugga ASCII-data? Det lämnar jag till dig att lista ut.
Hur brukar du lösa "big endian" och "little endian" i binära dataströmmar? Med strängar blir det trivialt.
Hur debuggar du binärdata på väg mellan två system? Jo du använder något verktyg som kan tolka protokollet. Inget konstigt.
Debugga ASCII-data? Det lämnar jag till dig att lista ut.
Re: Tolka oregelbunden data - Klient och Server
> Är inte det lite "nybörjarfasoner"?
Nej. Definiera ett enkelt meddelandeformat som ett paket med enbart "skrivbara tecken".
D.v.s att du konverterar dina numeriska värden till ASCII hex 30-39. Plus eventuell
annan text som du också vill överföra. Ge det en fast längd och kända start och slut
tecken. Om du vill, en checksumma före sluttecknet, men behövs sällan idag, det
finns checksummor i underliggande protokoll, så det blir mer en kontroll av att
sändaren inte har gjort något fel.
När du kör på socket nivå så finns det ingen direkt koppling mellan vad som
sänds från ena sidan och vad du får hos mottagaren. Det du sänder kan komma
som två paket till mottagaren. På samma sätt kan två sändningar returneras
i samma "recv" anrop. Det är du som måste ha koll och pussla ihop det.
Eller om det står här: https://docs.python.org/2/howto/sockets.html:
"But if you plan to reuse your socket for further transfers, you need to realize that
there is no EOT on a socket. I repeat: if a socket send or recv returns after handling
0 bytes, the connection has been broken. If the connection has not been broken, you
may wait on a recv forever, because the socket will not tell you that there’s nothing more
to read (for now). Now if you think about that a bit, you’ll come to realize a fundamental
truth of sockets: messages must either be fixed length (yuck), or be delimited (shrug),
or indicate how long they are (much better), or end by shutting down the connection.
The choice is entirely yours, (but some ways are righter than others)."
Om du inte har har en nätverksnivå där du t.ex kan sätta en terminator för läsningen, så
får du hantera det själv. Kolla gärna sidan ovan, den beskriver ganska väl på ett generellt
sätt vad man behöver tänka på, oavsett om det är Python eller inte. Och om man inte har
någon "terminal driver" eller liknande i OS'et som hanterar detaljerna åt en.
Och precis som lillahuset så har jag samma erfarenhet efter att byggt kommunikationsprogram
för produktionsutrustning i 35 år. KISS! Att skicka läsbar ASCII underlättar oerhört då man
debuggar. Bara att dumpa paketen i en logfil och läsa det direkt...
Nej. Definiera ett enkelt meddelandeformat som ett paket med enbart "skrivbara tecken".
D.v.s att du konverterar dina numeriska värden till ASCII hex 30-39. Plus eventuell
annan text som du också vill överföra. Ge det en fast längd och kända start och slut
tecken. Om du vill, en checksumma före sluttecknet, men behövs sällan idag, det
finns checksummor i underliggande protokoll, så det blir mer en kontroll av att
sändaren inte har gjort något fel.
När du kör på socket nivå så finns det ingen direkt koppling mellan vad som
sänds från ena sidan och vad du får hos mottagaren. Det du sänder kan komma
som två paket till mottagaren. På samma sätt kan två sändningar returneras
i samma "recv" anrop. Det är du som måste ha koll och pussla ihop det.
Eller om det står här: https://docs.python.org/2/howto/sockets.html:
"But if you plan to reuse your socket for further transfers, you need to realize that
there is no EOT on a socket. I repeat: if a socket send or recv returns after handling
0 bytes, the connection has been broken. If the connection has not been broken, you
may wait on a recv forever, because the socket will not tell you that there’s nothing more
to read (for now). Now if you think about that a bit, you’ll come to realize a fundamental
truth of sockets: messages must either be fixed length (yuck), or be delimited (shrug),
or indicate how long they are (much better), or end by shutting down the connection.
The choice is entirely yours, (but some ways are righter than others)."
Om du inte har har en nätverksnivå där du t.ex kan sätta en terminator för läsningen, så
får du hantera det själv. Kolla gärna sidan ovan, den beskriver ganska väl på ett generellt
sätt vad man behöver tänka på, oavsett om det är Python eller inte. Och om man inte har
någon "terminal driver" eller liknande i OS'et som hanterar detaljerna åt en.
Och precis som lillahuset så har jag samma erfarenhet efter att byggt kommunikationsprogram
för produktionsutrustning i 35 år. KISS! Att skicka läsbar ASCII underlättar oerhört då man
debuggar. Bara att dumpa paketen i en logfil och läsa det direkt...
Re: Tolka oregelbunden data - Klient och Server
läs på om protokoll, det är en grundläggande vedertagen metod för att göra det du vill göra...
- Jan Almqvist
- Inlägg: 1592
- Blev medlem: 1 oktober 2013, 20:48:26
- Ort: Orust
Re: Tolka oregelbunden data - Klient och Server
Att överföra numeriska värden som strängar kanske löser just endianness men har andra nackdelar. Ett problem är flyttal eftersom det finns flera olika tecken för decimaltecken. Det som fungerade hemma kanske inte fungerar ute hos kund i ett annat land.
Re: Tolka oregelbunden data - Klient och Server
Varför uppfinna hjulet på nytt?
Använd ett befintligt protokoll tex mqtt, modbus, canbus.
Använd ett befintligt protokoll tex mqtt, modbus, canbus.
Re: Tolka oregelbunden data - Klient och Server
TS är ju iofs både grundare och mest framträdande medlem i "vi som älskar att uppfinna hjul"
Re: Tolka oregelbunden data - Klient och Server
iofs kan ju hjuluppfinning, att skapa ett eget protokoll vara nyttigt bara för att lära sig hur det fungerar...
det kan ju vara svårt för många att kunna förutse eller tolka vilka problem som uppstår...
men det får väl forumet hjälpa till med,
det kan ju vara svårt för många att kunna förutse eller tolka vilka problem som uppstår...
men det får väl forumet hjälpa till med,
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Tolka oregelbunden data - Klient och Server
Det är rätt att decimaltecknet är ett litet irritationsmoment, men mycket litet.
Re: Tolka oregelbunden data - Klient och Server
header, footer och checksumma kommer man långt med
Re: Tolka oregelbunden data - Klient och Server
> Ett problem är flyttal...
Om man nu, som i detta fall, har full kontroll på båda ändar så är det sällan problem.
Om man t.ex vill överföra sekunder med 2 decimaler så skickar man millisekunder istället.
Om hur som helst, om man kontrollerar båda ändar så vore det ju lite korkat att använda
decimalpunkt i enda änden men decimalkomma i den andra.
Om man nu, som i detta fall, har full kontroll på båda ändar så är det sällan problem.
Om man t.ex vill överföra sekunder med 2 decimaler så skickar man millisekunder istället.
Om hur som helst, om man kontrollerar båda ändar så vore det ju lite korkat att använda
decimalpunkt i enda änden men decimalkomma i den andra.
- Jan Almqvist
- Inlägg: 1592
- Blev medlem: 1 oktober 2013, 20:48:26
- Ort: Orust
Re: Tolka oregelbunden data - Klient och Server
Korkat och kortat, det är så det kan bli om man t.ex låter sprintf() och motsvarande funktioner välja separator själv. Jag kan tänka mej att många gladeligen skulle skicka flyttal mellan olika system så här utan att inse riskerna.
Jag tycker att en annan nackdel med strängar är att de blir olika långa beroende på värdet.
Exempel:
"0" blir en (1) byte. "2.7181828459045" blir femton (15) byte.
Jag tycker att en annan nackdel med strängar är att de blir olika långa beroende på värdet.
Exempel:
"0" blir en (1) byte. "2.7181828459045" blir femton (15) byte.
Re: Tolka oregelbunden data - Klient och Server
Det är inte heller något problem... Självklart ska meddelanden
definieras antingen med kända avgränsare eller med ett fast format.
Personligen föredrar jag ett fast format, det är enklare att jämföra
olika meddelanden med varandra om allt ligger på samma plats. Med
ett fast format blir det "0.0000000000000" eller "2.7181828459045".
definieras antingen med kända avgränsare eller med ett fast format.
Personligen föredrar jag ett fast format, det är enklare att jämföra
olika meddelanden med varandra om allt ligger på samma plats. Med
ett fast format blir det "0.0000000000000" eller "2.7181828459045".