Sockety - obróbka danych

Witam . . .

Mam prośbę o jakieś konstruktywne sugestie
dotyczące poprawnego przesyłania danych
przez sockety, mam oczywiście na myśli dane
binarne, jak ustrzec się przed problemami
dotyczącymi tego że jak się wyśle dwie
małe porcje informacji po sobie to dochodzą
w jednej ?

Jak inne programy to rozwiązują (np. GG)

Czy istnieje możliwość że porcje danych nie
przyjdą w odpowiedniej kolejności, czy zdarzenia
OnRead są generowane w osobnych wątkach ? bo
to by znaczyło że jeśli jakaś porcja danych się
spóźni to kolejna może ją wyprzedzić...

Jak to się ma do ServerType stNonBlocking i
ThreadBlocking, z tego co czytałem w Helpie
to ThreadBlocking powinno być dobrą opcją ale
jedyne co robi to zawiesza aplikacje...

Jeśli chodzi o działanie socketów, to nie wiem wiele, ale mam pewien pomysł, który mógłby rozwiązać problem z lączeniem, a nawet zamienianiem kolejności pakietów: po prostu pierwsze 4 bajty każdego zawierałyby jego numer (osobna numeracja dla klienta i serwera), dwa następne - długość. W ten sposób rozdzielenie pomieszanego zlepka danych byłoby możliwe, a przy dużych pakietach dodatkowe 6 bajtów to nie problem.

hmmm... pomyślę, chociaż to dosyć będzie skomplikoane :-/

BTW chciałem pokazać największą beznadziejność
tego tworzenia zdarzeń i wątków:

wysyłamy w kliencie tekst:

ClientSocket.Scoket.SendText('111222333');

odbieramy w serverze:

• i teraz jak damy tak:

  var
    Tab : Array[0..2] of Char;
  begin
    Socket.ReceiveBuf(Tab, SizeOf(Tab));
    ListBox.Items.Add(Tab);
  end;

to w ListBoxie pojawi się:

111
222
333

• natomiast jeśli damy taki kod:

  var
    Tab : Array[0..2] of Char;
  begin
    Socket.ReceiveBuf(Tab, SizeOf(Tab));
    Application.ProcessMessages;
    ListBox.Items.Add(Tab);
  end;

to w ListBoxie pojawi się:

333
222
111

beznadzieja.... [glowa]

Jeżeli używasz protokołu połączeniowego to teoretycznie NIEMOŻLIWE JEST ŻEBY DANE DOSZŁY W ZŁEJ KOlEJNOŚĆI, bo wszystkie pakiety są numerowane, więc nie musisz się o to martwić.

var
Tab : array[0..2] of Char;
begin
Socket.ReceiveBuf(Tab, SizeOf(Tab));
ListBox.Items.Add(Tab);
end;

to w ListBoxie pojawi się:

111
222
333

• natomiast jeśli damy taki kod:

  var
  Tab : array[0..2] of Char;
  begin
  Socket.ReceiveBuf(Tab, SizeOf(Tab));
  Application.ProcessMessages;
  ListBox.Items.Add(Tab);
  end;

to w ListBoxie pojawi się:

333
222
111

beznadzieja....

nie jest beznadziejne, bo komponents clientsocket w procedurze sendtext wysyla na końcu #13+#10

jeżeli chcesz tego uniknąć to używaj funkcji sendbuf

nie jest beznadziejne, bo komponents clientsocket w procedurze sendtext wysyla na końcu #13+#10

jeżeli chcesz tego uniknąć to używaj funkcji sendbuf

Nie prawda, Sendtext nie powoduje dodania CR i LF na końcu.

Dane binarne można wysyłać jako normalny String.
Dodawaj na początku każdego pakietu nagłówek z numerem pakietu i jego długością. Długośc pozwoli Ci pociąć porcję danych na odpowiednie kawałki w momencie zlepienia pakietów.

nie jest beznadziejne, bo komponents clientsocket w procedurze sendtext wysyla na końcu #13+#10

a nawet gdyby (chociaż tak nie jest) to czy to tłumaczy
to że pakiety dochodzą w odwrotnej kolejności ?

a, rozumiem, troszku siem spieszyłem i szybko przeleciałem ten kod, wątpię żeby pakiety przychodziły w odwrotnej kolejnośći, może to z listboxem jest coś nie tak i kolejne add powoduje dodanie wpisu na samej górze, a co do sendtext to dodaje on na końcu CR LF!!! przynajmniej na Delphi 5, zresztą była już nawet o tym mowa na forum.

a, rozumiem, troszku siem spieszyłem i szybko przeleciałem ten kod, wątpię żeby pakiety przychodziły w odwrotnej kolejnośći, może to z listboxem jest coś nie tak i kolejne add powoduje dodanie wpisu na samej górze

chyba znowu troszku sie spieszyłeś i szybko przeleciałeś ten kod :p
problem w tym że nie odczytanie całych danych z bufora
wywołuje jeszcze raz tę procedurę ale jeśli da się ProcessMessages
to jest ona wywoływana już w tym momencie w osobnym wątku
i stąd odwrócona kolejność zapisu danych, które oczywiście
przychodzą w dobrej kolejności

ilustracja:
[code]
odbiór1
ProcessMessages1 odbiór2
ProcessMessages2 odbiór3
ProcessMessages
zapis3
zapis2
zapis1
[/code]
oczywiście to jest moja interpretacja i mogę się mylić...

a co do sendtext to dodaje on na końcu CR LF!!! przynajmniej na Delphi 5, zresztą była już nawet o tym mowa na forum

no to może na Delphi 5 tak jest, sorry . . .