Skicka bytes eller strängar till datorn?

[Jan Almqvist]

Till en dator skulle jag aldrig skicka något annat än bytes och alltid med något slags protokoll.

Ett heltal som t.ex. 1, 2, 4 eller 8 bytes och decimaltal som t.ex 4 eller 8 bytes ( IEEE 754 ).

[bearing]

OK, men vad är i så fall din kommentar till nackdelarna med att skicka rå data, som skrivits tidigare i tråden?

[Jan Almqvist]

OK, men vad är i så fall din kommentar till nackdelarna med att skicka rå data, som skrivits tidigare i tråden?

Vad menar du med "råa data"?

[bearing]

Jag kallar ditt sätt för "rått". Att skicka variablerna som råa bytes (plus protokoll/checksummor/liknande), utan att konvertera till en ASCII-sträng.

Problemet är ju hur datan ska pusslas ihop i andra änden. Vad händer om andra änden inte använder IEEE 754, och inte har samma endian, t.ex.

[Jan Almqvist]

Byte-ordning ser jag inte som ett stort problem. Jag skickar byte för byte i den ordning som protokollet anger. Mottagande sida tar emot byte för byte och får vid behov kasta om ordningen om den inte stämmer med protokollet.

Skulle mottagande eller sändande sida inte använda IEEE 754 så får denna sida konvertera till/från sitt format för flyttal och IEEE 754. Vi måste prata om en mycket ovanlig situation, har du något exempel?

Det som jag ser med den stora nackdelen med att skicka flyttal som en sträng t.ex. "3.14" är att det finns flera alternativ för decimaltecken. Använder man färdiga funktioner, t.ex. sscanf(), så är risken stor att det inte fungerar på en dator med andra nationella inställningar.

[bearing]

Ja, det måste vara en väldigt ovanlig situation. Kanske sodjan, som brukar nämna problemet, har något exempel.

Jag har skickat rå data i ett enkelt protokoll vid de tillfällen det måste gå oerhört snabbt, och bithastigheten redan är maxad. Annars använder jag alltid ASCII-strängar, eftersom att det är så enkelt att övervaka/felsöka/logga då. Behövs bara ett vanligt terminalprogram.

[Nerre]

Problemet med rå data är väl om man kommer ur synk. Om en float är 16 bitar så skickas den som två bytes, men vad händer om mottagaren av nån anledning "tappar" en byte? Då kommer det att bli pannkaka av alltihop.

[bearing]

Ja, man måste ha ett protokoll som hanterar sådana situationer. Vilket kan vara lite knepigt, eftersom att den råa datan som kommer in skulle kunna se ut som headern på protokollet.

[sodjan]

> Kanske sodjan, som brukar nämna problemet, har något exempel.

Många lösa tråder här... Vilket problem med specifikt?

> men vad händer om mottagaren av nån anledning "tappar" en byte?

Det i sig är ju samma sak om "123" skickas och "12", "13" eller "23" kommer fram.
Att "tappa tecken" är inget unikt för just binär överföring, så klart.

Nej, saken är mer den frågan som bearing nämner, att det är så oerhört mycket
enklare att testa och felsöka en kommunikation som enbart kör ASCII. Det går
att avlyssna och simulera valfri ände med enkla standardverktyg.

> Skulle mottagande eller sändande sida inte använda IEEE 754...
> ...Vi måste prata om en mycket ovanlig situation, har du något exempel?

Det finns massor av miljöer som inte nödvändigtsvis kör IEEE standard för
flyttal. Dels många som har helt mjukvaruimplementerade flyttal, men även
plattformar/processorer som har annan implementering i hårdvaran.

[Nerre]

Nej, men om man skickar "123<CR>" så "synkas" ju starten på nästa paket av <CR>.

Skickar man värdena 35 40 32 38 36 som 3 5 4 0 3 2 3 8 3 6 och det tappas bort en siffra så blir det 3 5 4 0 2 3 8 3 6 så är det svårt för mottagande sida att INTE tolka det som 35 40 23 83 6x.

Synkningen skulle ju kunna göras genom att skicka 3 5 - 4 0 - 3 2 - 3 8 - 3 6, tappas då en siffra blir det 3 5 - 4 0 - 2 - 3 8 - 3 6 och det är bara ETT värde som blir fel, inte "alla efterkommande".

Problemet med att skicka bytes är ju att det finns inget värde som inte kan förekomma i datat, alltså finns det inget "skiljetecken".

(Nu använde jag decimaltal uppdelat på ental och tiotal för att illustrera principen.)

[Jan Almqvist]

Ja, man måste ha ett protokoll som hanterar sådana situationer. Vilket kan vara lite knepigt, eftersom att den råa datan som kommer in skulle kunna se ut som headern på protokollet.

Att datadelen ibland kan se ut exakt som headern spelar faktiskt ingen roll.

[bearing]

Hm, är du säker?
Det måste väl ändå bero på hur protokollet är gjort.

Om vi säger att detta är protokollet:
Start Datalängd Data Checksumma

Låt säga att sändaren skickar ett paket med datalängd 4, och dessa fyra bytes råkar se ut som ett paket med datalängd 1. Om mottagaren sätts igång precis när datan som ser ut som ett paket skickas, borde väl mottagaren "tro" att den fått ett riktigt paket?

[Jan Almqvist]

Hm, är du säker?
Det måste väl ändå bero på hur protokollet är gjort.

Om vi säger att detta är protokollet:
Start Datalängd Data Checksumma

Låt säga att sändaren skickar ett paket med datalängd 4, och dessa fyra bytes råkar se ut som ett paket med datalängd 1. Om mottagaren sätts igång precis när datan som ser ut som ett paket skickas, borde väl mottagaren "tro" att den fått ett riktigt paket?

Jag är helt säker men ett riktigt protokoll inkluderar ju också timeouter och handskakning.

[bearing]

Ja, men då håller vi ju med varandra. Att det går att lösa förstod jag. Men det är inte helt enkelt.