|
|
 | ClientSocket, Serversocket
Fra : Ulrik Vadstrup |
Dato : 18-08-02 09:55 |
|
Jeg er begyndet at kigge lidt på TClientsocket, og TServersocket i D5, da
jeg skal bruge det til en application.
Jeg har lavet et lille test program, men er kommet i tvivl om følgende:
Hvad hvis jeg sender 3 - 4 strings til eks. TClientSocket, lige i røven af
hinnanden. Bliver de "Buffet" og rykket frem hver gang jeg laver en str :=
Clientsocket.recivetext ?
Eller hvordan håndterer jeg det ?
--
Med venlig hilsen
Ulrik Vadstrup
| |
 Harald (18-08-2002)
| Kommentar
Fra : Harald |
Dato : 18-08-02 19:54 |
|
"Ulrik Vadstrup" <blackend@blackend.dk> skrev i en meddelelse
news:3d5f6146$0$88355$edfadb0f@dspool01.news.tele.dk...
> Jeg er begyndet at kigge lidt på TClientsocket, og TServersocket i D5, da
> jeg skal bruge det til en application.
>
> Jeg har lavet et lille test program, men er kommet i tvivl om følgende:
>
> Hvad hvis jeg sender 3 - 4 strings til eks. TClientSocket, lige i røven af
> hinnanden. Bliver de "Buffet" og rykket frem hver gang jeg laver en str :=
> Clientsocket.recivetext ?
>
> Eller hvordan håndterer jeg det ?
Du får dem lige i røven af hinnanden så du er nød til at sætte et kontrol
tegn ind der fortæller hvor strengen slutter.
Jeg kan poste den måde jeg plejer at gøre det på hvis det skal være.
Mvh
HK
| |
Klaus Petersen (20-08-2002)
| Kommentar
Fra : Klaus Petersen |
Dato : 20-08-02 16:34 |
|
> Du får dem lige i røven af hinnanden så du er nød til at sætte et kontrol
> tegn ind der fortæller hvor strengen slutter.
Der er der da i forevejen - terminating-zero - en nul byte, der indikerer
slutningen på strengen.
| |
 Harald (22-08-2002)
| Kommentar
Fra : Harald |
Dato : 22-08-02 16:39 |
|
"Klaus Petersen" <spektual@hotmail.com> skrev i en meddelelse
news:ajtnji$od0$1@sunsite.dk...
> > Du får dem lige i røven af hinnanden så du er nød til at sætte et
kontrol
> > tegn ind der fortæller hvor strengen slutter.
>
> Der er der da i forevejen - terminating-zero - en nul byte, der indikerer
> slutningen på strengen.
Hvis du laver en test så vil du finde ud af at sådan er det ikke.
Mvh
HK
| |
Klaus Petersen (23-08-2002)
| Kommentar
Fra : Klaus Petersen |
Dato : 23-08-02 10:30 |
|
> Hvis du laver en test så vil du finde ud af at sådan er det ikke.
??? jeg ved ikke hvordan du har lavet din test.... mine tests påviste at den
er god nok...
| |
Harald (23-08-2002)
| Kommentar
Fra : Harald |
Dato : 23-08-02 20:58 |
|
"Klaus Petersen" <spektual@hotmail.com> skrev i en meddelelse
news:ak4vbc$je$1@sunsite.dk...
> > Hvis du laver en test så vil du finde ud af at sådan er det ikke.
>
> ??? jeg ved ikke hvordan du har lavet din test.... mine tests påviste at
den
> er god nok...
Jeg sender f.eks. 3 strenge sådan.
for i:=1 to 3 do
begin
ClientSocket.Socket.SendText('Test');
// evt. med en Application.ProcessMessages;
end
på en anden PC modtager jeg så de 3 strenge med et enkelt kald sådan:
tekst:=Socket.ReceiveText
og text er derefter = "TestTestTest"
det skal dog siges at engang i mellem så skal Socket.ReceiveText kaldes 2
gange, efter 1. kald er tekst="Test", efter andet kald er tekst="TestTest"
Hvis jeg samtidig belaster mit netværk så skal der nogle gange 3 kald til
Socket.ReceiveText.
Mvh
HK
| |
Klaus Petersen (25-08-2002)
| Kommentar
Fra : Klaus Petersen |
Dato : 25-08-02 15:14 |
|
Okay.. men hvis du bruger den metode, der modtager en "untyped" buffer i
stedet, og skriver de data ud i en fil, som du har modtaget, vil du via. en
hex-editor kunne se, at strengene modtages fint nok med et 0 mellem hver
streng. Du vil med rimelig lethed kunne lave en lille parser, der skiller
strengene fra hinanden og så er det problem løst.
Det er muligt, at receivetext laver et eller crap således at nogle strenge
bliver lagt sammen, men ovenstående algoritme virker fint nok.
| |
Harald (25-08-2002)
| Kommentar
Fra : Harald |
Dato : 25-08-02 16:02 |
|
"Klaus Petersen" <spektual@hotmail.com> skrev i en meddelelse
news:akaomg$76t$1@sunsite.dk...
> Okay.. men hvis du bruger den metode, der modtager en "untyped" buffer i
> stedet, og skriver de data ud i en fil, som du har modtaget, vil du via.
en
> hex-editor kunne se, at strengene modtages fint nok med et 0 mellem hver
> streng. Du vil med rimelig lethed kunne lave en lille parser, der skiller
> strengene fra hinanden og så er det problem løst.
>
> Det er muligt, at receivetext laver et eller crap således at nogle strenge
> bliver lagt sammen, men ovenstående algoritme virker fint nok.
Nu har jeg så prøvet med den anden metode dvs. Socket.ReceiveBuf og det
giver samme resultat, dvs. hvis jeg sender 3x "Test" får jeg "TestTestTest"
og så en #0 som afslutning i min buffer som er en array(.0..100.) of byte.
Så det er jo lidt mystisk.
Mvh
HK
| |
Harald (25-08-2002)
| Kommentar
Fra : Harald |
Dato : 25-08-02 16:24 |
|
"Harald" <swobu@kroning.dk> skrev i en meddelelse
news:3d68f161$0$43914$edfadb0f@dspool01.news.tele.dk...
> "Klaus Petersen" <spektual@hotmail.com> skrev i en meddelelse
> news:akaomg$76t$1@sunsite.dk...
> > Okay.. men hvis du bruger den metode, der modtager en "untyped" buffer i
> > stedet, og skriver de data ud i en fil, som du har modtaget, vil du via.
> en
> > hex-editor kunne se, at strengene modtages fint nok med et 0 mellem hver
> > streng. Du vil med rimelig lethed kunne lave en lille parser, der
skiller
> > strengene fra hinanden og så er det problem løst.
> >
> > Det er muligt, at receivetext laver et eller crap således at nogle
strenge
> > bliver lagt sammen, men ovenstående algoritme virker fint nok.
>
> Nu har jeg så prøvet med den anden metode dvs. Socket.ReceiveBuf og det
> giver samme resultat, dvs. hvis jeg sender 3x "Test" får jeg
"TestTestTest"
> og så en #0 som afslutning i min buffer som er en array(.0..100.) of byte.
> Så det er jo lidt mystisk.
Lige en rettelse, der bliver ikke sat et #0 ind for at markere slutningen,
det var bare noget skrald fordi jeg ikke havde nulstillet arrayet.
Mvh
HK
| |
|
|