-
Problem natury teoretycznej - ważny
Pisze serwer, z którego będzie można pobierać różne pliki. Kiedy serwer otrzyma żądanie pliku, wysyła klientowi małą porcję danych, następnie klient zgłasza, że chce następną porcję, serwer ją wysyła, i tak dalej, aż do końca pliku. Metoda może trochę dziwaczna, ale podobno sprawdza się dużo lepiej, niż wysyłanie od razu całego pliku (np. metoda sendstream clientsocketa) i odbieranie potem jego porcji w kliencie, z czym osobiście miałem problemy. Natomiast pierwsze rozwiązanie ma pewną wadę, tak mi się przynajmniej wydaje. Musiłaby być chyba stale otwarty plik, bo jakby go cięgle otwierać i zamykać to mogłoby zmniejszyć prękość przesyłu (tak sądzę). Przy jednym pliku nie byłoby to problemem, ale co z sytuacją, gdy plików jest kilkaset? Może jakaś tablica otwartych strumieni? Co sądzicie o tym wszystkim? -
W jaki sposób pobrać w win xp bitmapy, przy pomocy których rysowane sa kontrolki? Wiem, ze jest to możliwe, kiedyś wpadł mi w ręce komponent, który miał cos wspólnego z zarządzaniem skinami, nie wiem jednak dokładnie, co on robił, bo na d7 nie działał, a źródeł już nie mam. W każdym razie, do komponentu dołaczony był programik (bez żadnych źródeł, sam exe), który pokazywał bitmapy wszystkich kontrolek windowsowych. Może ktoś się sptkał z jakimiś funkcjami winapi do tego?
hmm co do pytania 1 to mysle ze to wlasciwie nie jest wcale wada - przynajmnjiej jezeli piszesz w c/c++. Ja bym to zrobil podobnie, kiedy serwer otrzyma zadanie przesylu pliku, dodaje do listy procesow proces danego klienta, w ktorym sa wszytskie informacje o tym co wyslac gdzie wyslac i na jaki port, a takze uchwyt do pliku. Pozniej to juz zwykla petla -> przetwarza liste procesow, ktorej dlugosc moze sie zmnieniac w trakcie dzialania programu serwera (klienci sie dolaczaja i odlaczaja). Tak czy siak to uzywanie uchwytow do pliku, ktory jest przetrzymywany w pamieci serwera, az plik zostanie przeslany w 100% to chyba dobra metoda.
ROZWIĄZANIE 1:
W BCB (a więc najpewniej i w Delphi) jest obiekt TMemoryStream. Ja bym zrobił (w c++) dynamiczną tablicę takich obiektów, które traktowałbym jak pliki [każdy z nich przy odebraniu żądania miałby przydzielony ID, np index w tablicy]. Byłoby to dobre rozwiązanie, jeśli danych miałoby być względnie mało, ponieważ wszystkie one były by przechowywane w pamięci, a dopiero na koniec zapisywane do plików.
ROZWIĄZANIE 2.
Można by też utworzyć plik tymczasowy (binarny oczywiście). Istniała by też tablica (struktur) dynamiczna zawierająca dane o plikach (głównie wielkość). Oczywiście zakładam, że przed rozpoczęciem pobierania znamy końcową wielkość pliku. Teraz gdy otrzymujemy żądanie od servera dopisujemy do tablicy dane nowego pliku a w nich między innymi pole zawierające sumie końcowych wielkości wszystkich poprzednich plików [np. [code]wszystkie[/code]], i pole zawierające dotychczas odebraną ilość danych tego pliku [np. [code]juz[/code]]. Teraz gdy otrzymamy od servera paczkę:
- ustawiamy wskaźnik plikowy pliku tmp na code[/code]
- Dopisujemy w tym miejscu odebrane dane
- Dopisujemy do [code]juz[/code] ilość odebranych danych.
Kiedy [code]juz[/code] będzie równe końcowej wielkości pliku kopiujemy odpowiednią część pliku tmp do nowego pliku, wszystkie nastepne elementy tablicy struktur przesuwamy o jeden w górę i od ich [code]wszystkie[/code] odejmujemy wielkość pliku, który się skończył ściągać...
To tylko idea, bo nie chce mi się opisywać całej procedury czyszczącej tmp i w ogóle zaniedbałem sporo szczegółów technicznych... Ale to tylko pomysł i tak sam będziesz musiał to napisać – niezależnie od tego jaką metodę wybierzesz :) ;p
Myślałem własnie o tablicy strumieni, jednak zdaje się, że bardziej się tu przyda TFileStream, niż TMemoryStream. Czy ktoś wie, ile miejsca w pamięci zajmuje FileStream? Bo chyba nie przechowuje w pamięci danych pliku, a jedynie jakiś wskaźnik? Czy opłaca się bardziej przechowywać w pamięci kilka/kilkadziesiąt FileStreamów, czy lepiej otwierać je co chwilę? Czy może jest jeszcze jakieś inne rozwiązanie?
ad 2. Theme Explorer, ma w swoich examples cos takiego. masa pisania...