---

Heysan!

Jeg mener at kunne huske et indlæg om objekter der blev
skrevet til disk, der så ikke kunne indlæses af et program
der var kompileret på en anden maskine. Dette kunne, så
vidt jeg husker, afhjælpes ved at indsætte et felt i
klassen. Hvad var det at det felt hed??

På forhånd tak

/ Michael

---

Hej Michael.

linien ser f.eks. således ud:
static final long serialVersionUID = 3388685877147921107L;

JEg kan pt. ikke lige huske en let måde at finde værdien på, men lad mig
lige tænke.

Mvh
Jonas


"Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
news:b9nlgt$2em$1@sunsite.dk...
> Heysan!
>
> Jeg mener at kunne huske et indlæg om objekter der blev
> skrevet til disk, der så ikke kunne indlæses af et program
> der var kompileret på en anden maskine. Dette kunne, så
> vidt jeg husker, afhjælpes ved at indsætte et felt i
> klassen. Hvad var det at det felt hed??
>
> På forhånd tak
>
> / Michael
>
>

---

"Jonas Zimling" <jonas.noSp@m.jazzedonjava.com> skrev i en meddelelse
news:_%Iva.32$l72.24@news.get2net.dk...
> Hej Michael.
>
> linien ser f.eks. således ud:
> static final long serialVersionUID = 3388685877147921107L;

Tak

> JEg kan pt. ikke lige huske en let måde at finde værdien på, men lad mig
> lige tænke.

Sun siger at man skal bruge "serialver" som følger med JDK det
lyder også meget fornuftigt, tror at de har ret

/ Michael

---

"Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
news:b9nmhp$7u4$1@sunsite.dk...
> bla bla bla bla bla bla bla bla
> bla bla bla bla bla bla bla bla

I øvrigt, hvis der er andre der skulle være interesseret i
at læse om det, fandt jeg det på:

http://developer.java.sun.com/developer/JDCTechTips/2001/tt0306.html#serialized



/ Michael

---

"Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
news:b9nlgt$2em$1@sunsite.dk...
> Heysan!

Luk!

> Dette kunne, så vidt jeg husker, afhjælpes ved at
> indsætte et felt i klassen. Hvad var det at det felt
> hed??

Fandt den selv

Så vidt jeg kunne se, drejer det sig om:

static final long serialVersionUID

> På forhånd tak

Det var så lidt

> / Michael

/ Michael

---

Så tag lige og kig på Externalizable nu du er igang. langt hurtigere og
smartere end Serializable. især hvis du vil have netværks kommunikation.

Kuruderu
"Michael Banzon" <anyone@anywhere.anyhow> wrote in message
news:b9nmbf$6tt$1@sunsite.dk...
> "Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
> news:b9nlgt$2em$1@sunsite.dk...
> > Heysan!
>
> Luk!
>
> > Dette kunne, så vidt jeg husker, afhjælpes ved at
> > indsætte et felt i klassen. Hvad var det at det felt
> > hed??
>
> Fandt den selv
>
> Så vidt jeg kunne se, drejer det sig om:
>
> static final long serialVersionUID
>
> > På forhånd tak
>
> Det var så lidt
>
> > / Michael
>
> / Michael
>
>

---

> Så tag lige og kig på Externalizable nu du er igang. langt hurtigere og
> smartere end Serializable. især hvis du vil have netværks kommunikation.

Smartere er så meget sagt. FOr det er den ikke. Serializable er meget mere
fleksibel end Externalizable, men dette er også grunden til at den er
langsommere. Så hvis man ikke skal bruge de smarte fordele som ligger i
Serializable så er det nok bedre at bruge Externalizable.

MVH

---

"Kuruderu" <kuruderu@dak.kollegie6400.dk> skrev i en meddelelse
news:3ebf97d7$0$97245$edfadb0f@dread12.news.tele.dk...
> især hvis du vil have netværks kommunikation.

Som jeg skrev i mit indlæg drejede det sig om objekter
der skulle skrives til disk... Jeg kunne _ALDRIG_ finde
på at sende hele objekter over netværk - LOL

/ Michael

---

>Jeg kunne _ALDRIG_ finde på at sende
>hele objekter over netværk - LOL

Du er sgu også så besværlig, din pong

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

"Trygleren [9000]" <Trygleren@SLETDETHERhesteskelet.dk> skrev i en
meddelelse news:3ebfaa49$0$83049$edfadb0f@dtext01.news.tele.dk...
> >Jeg kunne _ALDRIG_ finde på at sende
> >hele objekter over netværk - LOL
>
> Du er sgu også så besværlig, din pong

Jamen, jamen, jamen... det kunne jeg aldrig... netværk er
noget hø! Det er der ingen fremtid i!!! Jeg bruger det
ALDRIG!!!

(hmm... der faldt kæden vidst lige af... upsi!)

Nå, men, jeg kunne faktisk aldrig finde på at sende sådan
noget rod over netværket...

/ Michael

---

> Nå, men, jeg kunne faktisk aldrig finde på at sende sådan
> noget rod over netværket...

Enig. Basale datatyper == optimal netværkskommunikation.

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

> Enig. Basale datatyper == optimal netværkskommunikation.

Hvad er det lige du mener med det der ? .. Det giver jo ikke meget mening
så vidt jeg kan se :)

Mvh

Dennis T. HOlm

---

"Dennis T. Holm" <dennis@contempt.dk> skrev i en meddelelse
news:b9q2fq$v7$1@sunsite.dk...
>
> > Enig. Basale datatyper == optimal netværkskommunikation.
>
> Hvad er det lige du mener med det der ? .. Det giver jo ikke meget mening
> så vidt jeg kan se :)

Jeg tror at det han mener er at hvis han skal sende en integer, så sender
han en int og ikke en serialiseret Integer...

/ Michael

---

> > > Enig. Basale datatyper == optimal netværkskommunikation.
> >
> > Hvad er det lige du mener med det der ? .. Det giver jo ikke meget
mening
> > så vidt jeg kan se :)
>
> Jeg tror at det han mener er at hvis han skal sende en integer, så sender
> han en int og ikke en serialiseret Integer...
>

OK .. :) ..

---

> Jeg tror at det han mener er at hvis han skal sende en integer, så sender
> han en int og ikke en serialiseret Integer...

Jeg kunne ikke have sagt det smukkere selv =)

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

>Enig. Basale datatyper == optimal netværkskommunikation.
>
Absolut.
Prøv at sniffe pakker når du sender serialiserede objekter og se, hvad
det egentlig er, der bliver sendt. Jeg er for doven til lige at kode
noget selv, så jeg kan ikke vedhæfte et dump, men jeg gjorde det engang
og blev lidt overrasket.
For hvert objekt sendes selvfølgelig de data, objektet indeholder, men
der sendes også en h******* masse meta data, altså tekststrenge, som
beskriver hvad det næste i pakken er, så pakkerne kommer til at fylde
4-5 gange så meget, som de behøvede.
Hvis det ikke er et problem, så er serialiserede objekter en del nemmere
at arbejde med, men det spilder en masse båndbredde, så man må lige
overveje, hvad der er vigtigst.

Robert

http://www.ethereal.com/ <---Den (efter min mening) bedste netværks
sniffer der findes....og så er den gratis.

---

> For hvert objekt sendes selvfølgelig de data, objektet indeholder, men
> der sendes også en h******* masse meta data, altså tekststrenge, som
> beskriver hvad det næste i pakken er, så pakkerne kommer til at fylde
> 4-5 gange så meget, som de behøvede.

kommer da ikke til at fylde mere. Pakke skal da ha vedhæftet en header osv.,
så jeg tvivler på at der er en masse data vedhæftet som ikke skal være der
:) ..

MVH Dennis T. Holm

---

Dennis T. Holm wrote:

>>For hvert objekt sendes selvfølgelig de data, objektet indeholder, men
>>der sendes også en h******* masse meta data, altså tekststrenge, som
>>beskriver hvad det næste i pakken er, så pakkerne kommer til at fylde
>>4-5 gange så meget, som de behøvede.
>
>
> kommer da ikke til at fylde mere. Pakke skal da ha vedhæftet en header osv.,
> så jeg tvivler på at der er en masse data vedhæftet som ikke skal være der
> :) ..
>
> MVH Dennis T. Holm
>
>
Jo. Den fylder meget mere. Når jeg kommer hjem fra arbejde skal jeg nok
lige kode et eller andet og sniffe på det, så du kan se det selv. Der
kommer MEGET meta data med en pakke af serialiseret data.

Vent tålmodigt

Robert

---

"Robert Larsen" <Xrcl@ttpcom.com> skrev i en meddelelse
news:b9quk9$2ps$1@sunsite.dk...
> Vent tålmodigt

Vi venter med spænding

/ Michael

P.S. LOL / LMFAO
Men måske skulle vi holde os fra alt der
omhandler netværk, som jeg skrev tidligere,
der er slet ingen fremtid i det, ingen af
"de store firmaer" gider at bruge tid på det.
Og det der "internet" som man hører så meget
om fra de unge mennesker på MTV, det er er
da vidst nok en døgnflue i 23. time!

---

Michael Banzon wrote:

> "Robert Larsen" <Xrcl@ttpcom.com> skrev i en meddelelse
> news:b9quk9$2ps$1@sunsite.dk...
>
>>Vent tålmodigt
>
>
> Vi venter med spænding

UPS...jeg faldt vist i søvn i stedet

Well..her kommer det så. Jeg sendte en pakke som indeholdt en String, en
integer og en java.awt.Color (kode senere) og dette er selve datadelen
(ikke ethernet/IP/TCP delen) af pakken som Ethereal opsnappede:

0000 00 04 75 c2 c8 fb 02 08 74 ea b0 5d 08 00 45 00 ..u.....t..]..E.
0010 01 25 39 53 40 00 80 06 03 87 c0 a8 80 9a d4 0a .%9S@...........
0020 a7 ab 04 bb 13 88 0f 39 87 59 7c 40 ed a9 50 19 .......9.Y|@..P.
0030 fa f0 79 97 00 00 73 72 00 12 4d 79 53 65 72 69 ..y...sr..MySeri
0040 61 6c 69 7a 65 64 4f 62 6a 65 63 74 84 f1 3d ee alizedObject..=.
0050 1e 83 b9 bc 02 00 03 49 00 0b 73 6f 6d 65 49 6e .......I..someIn
0060 74 65 67 65 72 4c 00 06 61 43 6f 6c 6f 72 74 00 tegerL..aColort.
0070 10 4c 6a 61 76 61 2f 61 77 74 2f 43 6f 6c 6f 72 .Ljava/awt/Color
0080 3b 4c 00 07 61 53 74 72 69 6e 67 74 00 12 4c 6a ;L..aStringt..Lj
0090 61 76 61 2f 6c 61 6e 67 2f 53 74 72 69 6e 67 3b ava/lang/String;
00a0 78 70 00 00 00 07 73 72 00 0e 6a 61 76 61 2e 61 xp....sr..java.a
00b0 77 74 2e 43 6f 6c 6f 72 01 a5 17 83 10 8f 33 75 wt.Color......3u
00c0 02 00 05 46 00 06 66 61 6c 70 68 61 49 00 05 76 ...F..falphaI..v
00d0 61 6c 75 65 4c 00 02 63 73 74 00 1b 4c 6a 61 76 alueL..cst..Ljav
00e0 61 2f 61 77 74 2f 63 6f 6c 6f 72 2f 43 6f 6c 6f a/awt/color/Colo
00f0 72 53 70 61 63 65 3b 5b 00 09 66 72 67 62 76 61 rSpace;[..frgbva
0100 6c 75 65 74 00 02 5b 46 5b 00 06 66 76 61 6c 75 luet..[F[..fvalu
0110 65 71 00 7e 00 06 78 70 00 00 00 00 ff ff c8 00 eq.~..xp........
0120 70 70 70 74 00 0d 48 65 6c 6c 6f 2c 20 57 6f 72 pppt..Hello, Wor
0130 6c 64 21 ld!

Det er 307 bytes. Kig i ASCII afkodningen, så kan man se at indholdet af
objektet bliver beskrevet med tekst, som også sendes med, og det er dét
der gør det uoptimalt. Hvis jeg havde sendt strengen, integeren og Color
objektets tre integers for sig kunne jeg have klaret mig med 33 bytes (4
integers + teksten, som er 13 bytes + længden af teksten som med UTF
vist nok er endnu en integer). I stedet sender jeg 307 bytes.
Hvis man vil optimere net delen og udelukkende sende simple datatyper
bliver man selvfølgelig også nødt til at sende et eller andet, som
indikerer, hvad det næste, der kommer er, men man burde under alle
omstændigheder kunne gøre det bedre end javas serializer.

Koden jeg brugte er her, og det er IKKE en demonstration af pæn kode :

import java.net.*;
import java.io.*;
import java.awt.Color;

public class Client
{
   public Client(InetAddress adr, int port, MySerializedObject toSend)
throws IOException
   {
      //Create socket
      Socket s = new Socket(adr, port);

      //Get output stream
      ObjectOutputStream out = new ObjectOutputStream(s.getOutputStream());

      //Send the object
      System.out.println("Sending "+toSend);
      out.writeObject(toSend);

      //Close down
      s.close();
   }

   public static void main(String args[])
   {
      //Defaults...too lazy to parse command line options
      String host = "127.0.0.1";
      int port = 9999;
      String str = "Hello, World!"; //To stick with tradition
      int integer = 7; //Just for good luck
      Color color = Color.ORANGE;

      MySerializedObject mso = new MySerializedObject(str, integer, color);

      try
      {
         InetAddress adr = InetAddress.getByName(host);
         new Client(adr, port, mso);
      } catch (IOException ioe)
      {
         ioe.printStackTrace();
      }
   }
}


import java.io.Serializable;
import java.awt.Color;

public class MySerializedObject implements Serializable
{
   static final long serialVersionUID = -8867238098392335940L;

   private String aString;
   private int someInteger;
   private Color aColor; //Just to make things more interesting

   public MySerializedObject(String str, int i, Color col)
   {
      aString = str;
      someInteger = i;
      aColor = col;
   }

   public String toString()
   {
      return "String: "+aString+" Integer: "+someInteger+" Color: "+aColor;
   }
}


import java.net.*;
import java.io.*;

public class Server
{
   public Server(int port) throws IOException, ClassNotFoundException
   {
      //Create server socket
      ServerSocket serverSocket = new ServerSocket(port);
      System.out.println("Listening on port "+port);

      //Receive a client
      Socket socket = serverSocket.accept();
      handle(socket);
      socket.close();
   }

   private void handle(Socket s) throws IOException, ClassNotFoundException
   {
      //We receive an object from the client so we need an object input stream
      ObjectInputStream in = new ObjectInputStream(s.getInputStream());

      Object o = in.readObject();
      if(! (o instanceof MySerializedObject))
      {
         System.err.println("We didn't receive what we expected.");
         return;
      }
      System.out.println(o);
   }

   public static void main(String args[])
   {
      //Default port
      int port = 9999;

      //If any arguments are provided assume it's a port number
      if(args.length > 0)
      {
         try
         {
            //This will throw exceptions if it is not a number
            port = Integer.parseInt(args[0]);
         } catch (Exception e)
         {
         }
      }

      try
      {
         new Server(port);
      } catch (Exception ioe)
      {
         ioe.printStackTrace();
      }
   }
}



Robert

---

> UPS...jeg faldt vist i søvn i stedet
>
> Well..her kommer det så. Jeg sendte en pakke som indeholdt en String, en
> integer og en java.awt.Color (kode senere) og dette er selve datadelen
> (ikke ethernet/IP/TCP delen) af pakken som Ethereal opsnappede:
>
> Det er 307 bytes. Kig i ASCII afkodningen, så kan man se at indholdet af
> objektet bliver beskrevet med tekst, som også sendes med, og det er dét
> der gør det uoptimalt. Hvis jeg havde sendt strengen, integeren og Color
> objektets tre integers for sig kunne jeg have klaret mig med 33 bytes (4
> integers + teksten, som er 13 bytes + længden af teksten som med UTF
> vist nok er endnu en integer). I stedet sender jeg 307 bytes.
> Hvis man vil optimere net delen og udelukkende sende simple datatyper
> bliver man selvfølgelig også nødt til at sende et eller andet, som
> indikerer, hvad det næste, der kommer er, men man burde under alle
> omstændigheder kunne gøre det bedre end javas serializer.
>

Jeps .. som nævnt før i denne her tråd, så burde man måske bruge
Externalizable hvis man ønsker hurtigere overførsel. Grunden til at
Serializable er langsommere er, at den tillader mange flere muligheder end
Externalizable.

Men som sagt har du ret i at der sendes en masse data med serializable, men
spørgsmålet er så om det ikke er nedarvet af at den er MEGET mere fleksibel
en Externalizable, som jo er en slags SKRABET udgave af Serializable.

Mvh Dennis T. Holm

---

"Dennis T. Holm" <dennis@contempt.dk> skrev i en meddelelse
news:b9t0gt$d2p$1@sunsite.dk...
>
> > Det er 307 bytes. Kig i ASCII afkodningen, så kan man se at indholdet af
> > objektet bliver beskrevet med tekst, som også sendes med, og det er dét
> > der gør det uoptimalt. Hvis jeg havde sendt strengen, integeren og Color
> > objektets tre integers for sig kunne jeg have klaret mig med 33 bytes (4
> > integers + teksten, som er 13 bytes + længden af teksten som med UTF
> > vist nok er endnu en integer). I stedet sender jeg 307 bytes.
> > Hvis man vil optimere net delen og udelukkende sende simple datatyper
> > bliver man selvfølgelig også nødt til at sende et eller andet, som
> > indikerer, hvad det næste, der kommer er, men man burde under alle
> > omstændigheder kunne gøre det bedre end javas serializer.
> >
>
> Jeps .. som nævnt før i denne her tråd, så burde man måske bruge
> Externalizable hvis man ønsker hurtigere overførsel. Grunden til at
> Serializable er langsommere er, at den tillader mange flere muligheder end
> Externalizable.

Serializable serializerer en objekt-graf automatisk, det gør Externalizable
ikke. Med Externalizable er du derimod tvunget til selv at tage stilling til
hvordan et objekt skal serializeres. Idet du selv har kontrol over
serializeringen vil jeg ikke sige at Externalizable giver færre muligheder
end Serializable, jeg vil snarre sige at du har flere muligheder. Det er
bare mere besværligt.

Problemet med hastigheden af Serializable er at der bruges reflection til at
serializere og deserializere, og det er dyrt. Hvis du skal gøre
serializeringen så hurtig som muligt, så skal dine klasser implementere
Externalizable, og du skal også passe på med at bruge readObject() og
writeObject(), da disse metoder også bruger reflection.

/Anders

---

Robert Larsen <Xrcl@ttpcom.com> writes:

> For hvert objekt sendes selvfølgelig de data, objektet indeholder, men
> der sendes også en h******* masse meta data, altså tekststrenge, som
> beskriver hvad det næste i pakken er, så pakkerne kommer til at fylde
> 4-5 gange så meget, som de behøvede.

Netværkstrafik er billig. Hvis båndbredden er lav, så lav en
komprimeret datakanal.

Der er heller ikke ret mange i dag der er nødt til at kode ud fra at
skulle spare plads på harddisken.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

> Der er heller ikke ret mange i dag der er nødt til at kode ud fra at
> skulle spare plads på harddisken.

Så derfor er whitespace heller ikke noget du tænker over?

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

"Trygleren [9000]" <Trygleren@SLETDETHERhesteskelet.dk> writes:

> > Der er heller ikke ret mange i dag der er nødt til at kode ud fra at
> > skulle spare plads på harddisken.
>
> Så derfor er whitespace heller ikke noget du tænker over?

Ikke for at spare plads på harddisken, nej.

Hvis det ikke er af hensyn til mængden af data over nettet, hvorfor er
man så utilfreds?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

> > Så derfor er whitespace heller ikke noget du tænker over?
>
> Ikke for at spare plads på harddisken, nej.
>
> Hvis det ikke er af hensyn til mængden af data over nettet, hvorfor er
> man så utilfreds?

Mit spørgsmål var nu mere af en principiel karakter. Optimere hvor, optimeres kan.
Blot fordi nettet er hurtigt nok, er vel ingen grund til at lave 'tung' kode?
Hvis vi får en kvantecomputer engang, begynder vi vel heller ikke at lave
O(n!)-algoritmer?

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

"Trygleren [9000]" <Trygleren@SLETDETHERhesteskelet.dk> writes:

> Mit spørgsmål var nu mere af en principiel karakter. Optimere hvor, optimeres kan.

Forkert. Optimere hvor der er behov derfor.

Det kan endda være at din kode til at understøtte optimeringen er
langsommere end det at flytte data. Se fx hvor hurtigt man kan flytte
data via ssh. Hos mig er det mærkbart en flaskehals når man kopiere
over net til bånd.

> Blot fordi nettet er hurtigt nok, er vel ingen grund til at lave
> 'tung' kode?

Det er et spørgsmål om hvor du ønsker at lægge din indsats, og hvilke
faciliteter du ønsker. Hvorfor optimere noget hvor optim

> Hvis vi får en kvantecomputer engang, begynder vi vel heller ikke at lave
> O(n!)-algoritmer?

Joda. Det er så vidt jeg kan se, hele fidusen.

Så er det ligemeget om P = NP eller ej.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

> > Hvis vi får en kvantecomputer engang, begynder vi vel heller ikke at lave
> > O(n!)-algoritmer?
> Joda. Det er så vidt jeg kan se, hele fidusen.
> Så er det ligemeget om P = NP eller ej.

For det første: Yoda staves med y =)
For det andet tror jeg min pointe går lidt tabt både i min egen formulering og derfor i dit svar.
Lad mig prøve at udrede hvad jeg mener - der er to sider af denne sag:

I P=NP problematikken HJÆLPER en kvantecomputer jo rent faktisk på
problemet, idet en kvantecomputer kan betragtes som en nondeterministisk
Turing-maskine, der forenklet sagt er en computer, der er i stand til at
prøve alle muligheder parallelt og vælge den rigtige. Med andre ord: En
kvantecomputer KAN løse problemerne i NP (og NPC) i polynomiel tid -
altså P=NP - den hjælper altså på O(n!) og de andre. Så der er vi faktisk enige, hehe.

Den anden side af sagen, som jeg troede du henviseste til, er, at en
kvantecomputer IKKE vil være i stand til at løse eksempelvis
standseproblemet. Med andre ord: Kvantecomputere hjælper IKKE på de
uafgørbare problemer - de er altså stadigvæk uafgørbare. De uafgørbare problemer
er altså anderledes, idet de beviseligt er uafgørbare uanset hvor smarte vi
så end er. Med andre ord: Der er ingen, der kan komme med en algoritme
eller en ny computerarkitektur, der kan knække de uafgørbare problemer.

Hvis du læser beviset for uafgørbarheden af standseproblemt (såfremt du ikke lige
kan huske det - ingen fornærmelse ment =) ), så vil du se, at vi i beviset IKKE stiller
nogen krav til køretiden af algoritmen - kun til eksistensen af en algoritme, som leder
til en modstrid. Beviset for uafgørbarheden er altså uafhængigt af køretiden af
algoritmen (og computerarkitektur), så konklusionen er, at ingen kan komme med en
algoritme til at løse problemet - heller ikke selvom vi er villige til at acceptere en algoritme,
der eksempelvis er O(n!).

Hvad man derimod godt kan (og rent faktisk gør i virkeligheden), er at
komme med en algoritme, der med meget stor sandsynlighed giver et
korrekt svar (men ingen garantier kan stilles, idet der stadigvæk er en
lille sandsynlighed for at give et forkert svar).

Kort sagt: En kvantecomputer hjælper altså på hastigheden, hvormed vi
kan løse de AFGØRBARE problemer (også den der i praksis er uløselige nu,
fordi de tager for lang tid), men hjælper os IKKE med at løse nogen af
de UAFGØRBARE problemer. Da jeg sagde, at det var ligegyldigt med
kvantecomputeren, så mente jeg altså i forhold til standseproblemet -
ikke hastigheden!

Håber det gjorde sagen mere klar. Jeg undskylder at jeg sidder i mine egne tanker
og snurrer rundt for mig selv =)


--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk <-- Honning og gaffa i en!

---

"Trygleren [9000]" <Trygleren@SLETDETHERhesteskelet.dk> writes:

> For det andet tror jeg min pointe går lidt tabt både i min egen formulering og derfor i dit svar.
> Håber det gjorde sagen mere klar. Jeg undskylder at jeg sidder i mine egne tanker
> og snurrer rundt for mig selv =)

Næh, sagen er ikke specielt mere klar. Kunne du ikke lige opsummere
dig selv, så klart og tydeligt at jeg er helt sikker på hvad du mener?

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Robert Larsen wrote:

> For hvert objekt sendes selvfølgelig de data, objektet indeholder, men
> der sendes også en h******* masse meta data, altså tekststrenge, som
> beskriver hvad det næste i pakken er, så pakkerne kommer til at fylde
> 4-5 gange så meget, som de behøvede.

Hmm .. Er det ikke bare en del af udviklingen, at man ikke længere behøver
at bekymre sig så meget om båndbredde? Jeg mener, se på en protokol som
SOAP. Det ligger næsten i luften, at man er ret ligeglad med det potentielt
ekstreme overhead på transmissionsmængden. Man har favoriseret læsbarhed og
åbenhed fremfor størrelse på pakkerne.

Efter min mening er det langt værre, hvis det kræver for mange kræfter at
pakke data ind og ud ved afsendelse og modtagelse.


--

Martin

---

"Martin Kofoed" <inzide@hot.mail.c.o.m> skrev:
> Hmm .. Er det ikke bare en del af udviklingen, at man ikke længere behøver
> at bekymre sig så meget om båndbredde? Jeg mener, se på en protokol som
> SOAP. Det ligger næsten i luften, at man er ret ligeglad med det
potentielt
> ekstreme overhead på transmissionsmængden. Man har favoriseret læsbarhed
og
> åbenhed fremfor størrelse på pakkerne.
>
> Efter min mening er det langt værre, hvis det kræver for mange kræfter at
> pakke data ind og ud ved afsendelse og modtagelse.

Nej!
Hvis du kigger på et typisk "båndbredde"-forbrug, lokalt v. globalt, altså
hhv. CPU og netværksbelastning, så vil de fleste opleve noget flere peaks
på netværket end på CPU'en, der oftest vil være idle. Båndbredden på CPU'en
er, som regel (LOL) væsentligt større end den på netværket. Jeg ville i
hvert
fald forsøge at minimere behovet for båndbredde der hvor der er mindst af
den, og omvendt der hvor der er rigeligt.

/ Michael

---

Michael Banzon wrote:
> "Martin Kofoed" <inzide@hot.mail.c.o.m> skrev:
>
>>Hmm .. Er det ikke bare en del af udviklingen, at man ikke længere behøver
>>at bekymre sig så meget om båndbredde? Jeg mener, se på en protokol som
>>SOAP. Det ligger næsten i luften, at man er ret ligeglad med det
>
> potentielt
>
>>ekstreme overhead på transmissionsmængden. Man har favoriseret læsbarhed
>
> og
>
>>åbenhed fremfor størrelse på pakkerne.
>>
>>Efter min mening er det langt værre, hvis det kræver for mange kræfter at
>>pakke data ind og ud ved afsendelse og modtagelse.
>
>
> Nej!
> Hvis du kigger på et typisk "båndbredde"-forbrug, lokalt v. globalt, altså
> hhv. CPU og netværksbelastning, så vil de fleste opleve noget flere peaks
> på netværket end på CPU'en, der oftest vil være idle. Båndbredden på CPU'en
> er, som regel (LOL) væsentligt større end den på netværket. Jeg ville i
> hvert
> fald forsøge at minimere behovet for båndbredde der hvor der er mindst af
> den, og omvendt der hvor der er rigeligt.
>
> / Michael
>
>
Der er intet entydigt svar på om det kan betale sig at optimere
netværkstrafik. Det kommer helt an på situationen. I min test
(andetsteds i tråden) sendte jeg faktisk næsten 10 gange så meget data,
som jeg behøvede. Hvis din software skal bruges af tusinder af brugere
så er det altså ikke helt ligemeget, om der flyttes 10 GB om dagen eller
100. Så begynder man på optimering og komprimering og caching og
redundering og ........

Omvendt, hvis du laver et ludospil kan det næsten være ligemeget om der
sendes et par megabytes ekstra pr. spil. Det må man overveje pr.
applikation.

Robert

---

"Robert Larsen" <Xrcl@ttpcom.com> skrev i en meddelelse
news:b9toqh$bc6$1@sunsite.dk...
> Det må man overveje pr. applikation.

Ja, klart, men du må da give mig ret i, mht. spørgsmålet vedrørende
decoding af data når det er nået frem, at man skal bruge
båndbredden der hvor den er. Altså i CPU'en.

/ Michael

---

"Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
news:b9u52c$guu$1@sunsite.dk...
> "Robert Larsen" <Xrcl@ttpcom.com> skrev i en meddelelse
> news:b9toqh$bc6$1@sunsite.dk...
> > Det må man overveje pr. applikation.
>
> Ja, klart, men du må da give mig ret i, mht. spørgsmålet vedrørende
> decoding af data når det er nået frem, at man skal bruge
> båndbredden der hvor den er. Altså i CPU'en.

Hvis data kun skal sendes over et lokalt 100 Mb eller 1Gb netværk, så er den
båndbredde sandsynligvis ikke det store problem. Så kan problemet sagtens
være at encode og decode data fra netværket.

Lige i øjeblikket har jeg det problem på arbejde, at der tabes alt for mange
UDP pakker på en maskine fordi den simplethen ikke er hurtig nok til at
følge med de data vi sender til den. Data (UDP) sendes over et 100 Mb
netværk, fra en P4 2.4 GHz Windows PC til en Celeron 600 MHz Linux maskine.
Med ren java i begge ender taber Linux maskine op til 80% af pakkerne. Hvis
vi derimod laver et C program til at læse pakkerne (den decoder ikke data),
så tabes der ingen pakker. Selvfølgelig vil vi tabe pakker i sådan et setup,
men 80%? Og så når C programmet slet ikke taber nogle?

Nå, det var vist et sidespor, men dog et eksempel på at der ikke altid er
nok CPU kraft.

/Anders

---

"Michael Banzon" <anyone@anywhere.anyhow> writes:

> Nå, men, jeg kunne faktisk aldrig finde på at sende sådan
> noget rod over netværket...

J2EE kan ikke fungere uden.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

"Michael Banzon" <anyone@anywhere.anyhow> skrev i en meddelelse
news:b9o6db$7g5$1@sunsite.dk...
> "Kuruderu" <kuruderu@dak.kollegie6400.dk> skrev i en meddelelse
> news:3ebf97d7$0$97245$edfadb0f@dread12.news.tele.dk...
> > især hvis du vil have netværks kommunikation.
>
> Jeg kunne _ALDRIG_ finde på at sende hele
> objekter over netværk

Hmmm.... det har jeg lige gjort alligevel, så denne
tråd er hermed anulleret!

/ Michael

P.S.: LOL