Hjælp til programmeringsopgave java + socket (forståelse)

En strøm (af det engelsk stream som i FileInputStream), i denne sammenhæng, betyder en sekvens af bytes eller tegnsæt. F.eks. FileInputStream bruges til at læse en strøm af bytes fra en fil. I netværk har man sockets som sender og modtager strømme af data.

Du skal ikke lede efter "sensor data" i Java; det er den del du skal genere. Hvordan er er fuldstændigt irrelevant så længe de overholdet kravet om 14-24 grader. Eksemplet med tastaturet som kilde er nok den som er nemmest at komme igang med og som hjælp til debugging.

Konverteringshalløjet er nødvendigt. Årsagen til du ikke må bruge den indbyggede serialisering pga. de forskellige maskinarkitektur. Nu er din opgave kun at simulere, men hvis nu klienten og modtageren fortolker klumper af bytes forskelligt får du forskellig resultat.

Lad os sige at du vil sende en 32 bit integer (int i Java) til serveren. Den fylder 4 bytes. To typiske måder at arrange dem på er enten at den første byte indeholder de højeste cifre af de 32 bit, dvs. bit 24-31. Anden byte indeholder bit 16-23 osv. Det vil se sådan her ud for tallet 20:

tallet 20 i fire bytes med ("big endian") = 0 0 0 20

Men hvis nu serveren gør det omvendte. Den læser den første byte som den laveste af de fire vil den læse de fire bytes ind som en 32 bit integer med værdien 335544320, hvilket vil betyde bygningen er brændt ned.

Så anden del af din opgave er at finde ud af hvordan du vil organisere dit netværksdata. Det som TCP gør for dig er at sørge for at alt du sender bliver modtaget på den anden side og ikke andet. Den sørger IKKE for at:

- En enkelt "send" kald på klienten betyder du kun skal læse en enkelt gang. Fordi du sender 10 bytes på klienten kan det godt risikere at skulle lave 2 eller flere reads på serveren (medmindre du bruger blocking io men nu begynder vi at gå i detaljer).

En måde at overkomme problemet med forskellige repræsentationer er, at du siger for din kommunikation er alle tal der består af flere bytes, enten med højeste cifre først, eller laveste cifre først altid.

Hvis du kun vil sende en temperature mellem 14-24 kan du tænke over om en minimal løsning overhovedet kræver at opdele data i flere bytes. Er en byte per temperaturmåling i netværkstrømmen ikke nok til at beskrive temperaturen?

God arbejdslyst

Mange tak for svar, dog er det forsat lidt sort med de bytes, da jeg aldrig rigtig har brugt dem før.

min tankegang er at i min klient læser nogle data fra en fil, lad os sige en txt fil der hedder "data.txt"

Den består fx har tal sådan her:

15 18 19 14 16 17 14 18 20.

Denne fil har jeg tænkt mig og hente ned og smide det i et array jeg læser igennem, hvor jeg gang den læser en linje, fx 15, så konveteres det til en byte og sendes til serveren.

Serveren opdaterer så gennemsnits temperaturen på en GUI som jeg hurtig bikser sammen med en formel.

Er der evt noget jeg har misforstået?

Hvis jeg forstår dig:

1. Du læser filen i linjer
2. Læser hver linje om til en byte
3. Sender hver byte til serveren

Det lyder som en fin plan. Hver byte er en "pakke" som i dette tilfælde er en temperature måling og så kan du sagtens sende dem og læse dem direkte på serveren og beregne det løbende gennemsnit.

Det er kun hvis dine "pakker" er større end en byte, eller der findes forskellige typer af pakker, at du skal gøre noget mere kompliceret. Dette er hvad din kursusanvarlige mener med at du ikke må bruge den indbyggede "serialiseringsfunktion", og der hvor problematikken med strukturet data og maskinarkitektur kommer ind i billedet. Men hvis dine pakker kun er en byte stor, dvs. dine temperaturmålinger, slipper du for at gøre din løsning mere kompleks.

Vigtig detalje: Når du laver din socket og får f.eks. en outputstream, så efter at du har kaldt .write med dine bytes, så husk at kalde .flush på din stream, ellers kan du risikere de bare ligger i hukommelsen et sted uden at blive sendt.