Niezawodne przesyłanie plików przez gniazda

Witam,
Muszę zaimplementować "dobre" przesyłanie plików przez gniazda, gdzie sieć niekoniecznie będzie 1Gb Ethernetem :>. Może implementował ktoś z Was takie rozwiązanie, które sprawdza się w praktyce ? Bo na localhoście to jedna sprawa, a w rzeczywistej sieci to druga...

Mniej więcej taki mam zamysł:

1. Pakuję plik 7zipem, (myślę ze pliki beda mialy max 1MB po upakowaniu)
2. Dzielę plik na 4096 bajtowe części (chyba taki optymalny będzie rozmiar części ?)
3. Generuje SHA-1 całego pliku
4. Przesyłam do drugiego węzła jakiś komunikat w deseń FILE#Wartosc_SHA1
5. Przesyłam częsci pliku
6. Przesyłam komunikat końca pliku, węzeł scala plik i sprawdza skrót.

Jakieś sugestie ?

Jak ja korzystałem z gniazd, to miałem taki algorytm:

1. Wysyłam polecenie FILE
2. Wysyłam nazwę oraz rozmiar pliku (w bajtach)
3. Wysyłam plik
   a) Wysyłam 10 KB* i czekam na polecenie PacketOK
   b) Jeżeli odebrałem PacketOK, to wysyłam następny pakiet.
4. Jeżeli odebrałem OK, to plik został wysłany poprawnie.

*****Jeżeli do odczytania zostało mniej, niż 10 KB, to wysyłam tyle, ile zostało do odczytania.

No czyli generalnie prawie taka sama idea.

A jak sobie radziłeś ze "zlepianiem" komunikatów ? Chyba ze nie występowalo takie coś u ciebie :>
Generalnie mając "stałe" postacie komunikatów, można sobie zrobić jakiś seperator końca polecenia (w razie gdyby TCP sobie dwa segmenty wysłało w jednym) i sobie ładnie wyodrębnić zawartość z pomiedzy separatorów. Lecz plik to losowy ciąg można by rzecz - więc tu troche gorzej ...

Poprawka:

1. Wysyłam polecenie FILE
   a) Czekam na CommandOK
2. Wysyłam nazwę oraz rozmiar pliku (w bajtach)
   a) Czekam na CommandOK
3. Wysyłam plik
   a) Wysyłam 10 KB* i czekam na polecenie PacketOK
   b) Jeżeli odebrałem PacketOK, to wysyłam następny pakiet.
4. Jeżeli odebrałem OK, to plik został wysłany poprawnie.

*Jeżeli do odczytania zostało mniej, niż 10 KB, to wysyłam tyle, ile zostało do odczytania.

Aby pakiety się nie nakładały, są polecenia CommandOK oraz PacketOK
U mnie przy zastosowaniu takiego algorytmu wszystko było OK (tj.u mnie w sensie przesyłania między dwoma komputerami, a nie między localhost)

Wybaczcie, ale.... TCP zapewnia, że pakiety dojdą w odpowiedniej kolejności i nie zaginą. To znaczy zaginą, jeśli sieć całkiem padnie. Więc po co wynajdywać koło od nowa ?

no własnie po to gdy sieć padnie ?

Niby ma retransmisję, nie wiem czy to wina implementacji socketów (piszę w Delphi), ale z tą niezawodnością nie jest tak różowo.

jak sieć padnie to i te wynalazki nic nie pomogą. Nie prościej napisać podstawowy serwer/klient FTP?

pomogą. Podczas gdy klient znów będzie aktywny, plik zostanie przesłany od nowa. To chyba oczywiste ??

ale co ma przesłanie od nowa do waszych wynalazków?

no to więc jakie idealne wyjście proponujesz ?

Generalnie to nie tylko pliki będą przesyłane lecz także normalne inne komunikaty.
Sockety do komunikatów i dodatkowo przez FTP transmisja ?

Generalnie przesyłam dane z BD i muszę miec pewność ze odebrał to drugi węzel i dopiero wtedy mogę usuwać przeslane dane z Bazy. (Stad nacisk na potwierdzenia).

napisz sobie webserwice

Generalnie przesyłam dane z BD i muszę miec pewność ze odebrał to drugi węzel i dopiero wtedy mogę usuwać przeslane dane z Bazy. (Stad nacisk na potwierdzenia).

Ale to do tego ci potrzebne potwierdzenia co 10KB?

(w razie gdyby TCP sobie dwa segmenty wysłało w jednym)

CO?

Podstawy sieci chłopaki... Jeśli korzystasz z TCP nie ma prawa być utraconych, zduplikowanych, w złej kolejności pakietów. Jeśli utracisz połączenie - dostaniesz błąd. Obsłuż błąd. Koniec filozofii.