Cześć,
nie wiem czy wyraziłem się poprawnie, ale chodzi mi o pośredniczenie w pobieraniu. Jest serwer z plikiem i użytkownik, teraz chcę żeby w pobieraniu między nimi pośredniczył jeszcze jeden serwer, ale żeby działało to w czasie rzeczywistym. Tylko teraz jak takie coś miałoby działać? Pomiędzy serwerem z plikiem, a użytkownikiem przekazywany byłby bajt po bajcie czy zapisywałoby się to powiedzmy w pamięci ram co za tym idzie zapychało ją. Proszę o pomoc w rozwiązaniu mojego problemu.
Np. z jednej maszyny do serwera wysyłasz plik, serwer odbiera np. paczki po 100kb i od razu je wysyła dalej. Nie wiem jaka byłaby najoptymalniejsza wielkość takiej paczki, ale można to sprawdzić empirycznie, ewentualnie ktoś kompetentniejszy się wypowie ;). Przesyłanie bajt bo bajcie byłoby raczej mocno nieefektywne, zresztą system sam by łączył takie luźne bajty w większe pakiety.
Dzięki za odpowiedź. Czekam na jeszcze jakieś inne informację.
Z jakiej biblioteki korzystasz przy obsłudze neta?
Generalnie co do ilości wysyłanych bitów czy bajtów za jednym pakietem nie masz się co przejmować, ponieważ teraz większość bibliotek sama sobie reguluje najwygodniejszą ilość przesyłanych bajtów.
Co do samego przesyłania Serwer->Twój program->Klient
Odbierasz dane i przesyłasz dalej. Nie widzę tutaj żadnego problemu.
Także nie wiem gdzie tu jakiś problem,
schemat twojego programu wyglądałby tak:
while( recv() ) send(); //łapiesz co przyjdzie i ślesz w nowej miejsce
ot cała filozofia
Tylko problem jest tego typu, że to ma iść przez przeglądarkę i będzie wywoływanie z poziomu php za pomocą exec. Dodatkowym utrudnieniem jest system - linux. Chodzi mi głównie o to pod jakim hasłem mam szukać streaming?
Jakim utrudnieniem? WinSocks są inspirowane przecież UNIX'owymi socketami i różnice są w 2 linijkach tak naprawdę co da się rozwiązać jednym ifem preprocesora.
Dzięki za info, nigdy nie programowałem w linuxie więc pytam :)
teraz to nie bardzo wiadomo o co mu chodzi bo pisze coś o streamingu, wcześniej o pośredniczeniu w przesyłaniu pliku...
streaming to generalnie idea podziału danych na niezależne paczki - stosowane na szeroką skalę w multimediach, np. mp3 składa się niezależnych paczuszek, np. możesz zacząć odtwarzanie mp3 od środka, łapiesz tylko pierwszy napotkany w środku nagłówek (pierwsza paczuszka) i lecisz dalej...
Może chodzi mu o implementację na maszynie pośredniczącej tego: http://pl.wikipedia.org/wiki/Real_Time_Streaming_Protocol
A mówiąc o odpalaniu z php, to domyślam się że chodzi o stronę klienta pobierającego, ale jeśli po prostu chodzi o odpalenie z php programu który ma wszystko robić, to co to ma do tematu?
Chłopak chyba sam już się pogubił, bo ja na pewno...
W każdym razie doszliśmy, że mamy 3 punkty: server z zasobem (rozumiem, że to jakaś maszyna do której nie mamy dostępu) <=> maszyna pośrednicząca (tu na razie nie doszliśmy jeszcze jak to ma działać) <=> klient pytający o zasób (jak dobrze rozumiem to tutaj mówi o tej przeglądarce + exec?)
Sannin napisał(a)
Dzięki za info, nigdy nie programowałem w linuxie więc pytam :)
eeeee... problem rozwiązany, to co jest tutaj problemem, bo już całkiem się pogubiłem o.0
Dlatego na samym początku napisałem: nie wiem czy wyraziłem się poprawnie, nie potrafiłem nazwać tego co chcę zrobić. Idea jest tak, jest serwer1 na którym są pliki, użytkownik wchodzi na serwer2 przez przeglądarkę i wybiera z listy plik, klika na pobranie i wtedy w php odpala się dajmy
exec("downloader -f http://serwer1.pl/pik1.zip");
Ten program ma za zadanie pobierać i w tym samym czasie wysyłać plik do użytkownika (nie wiem jak to nazwać proxy?), ale chodzi też o to, żeby plik nie był zapisywany w całości na dyską bądź w pamięci. To co zostało już wysłane ma zostać usunięte z pamięci. Chodzi mi tylko o to, żeby ktoś mnie nakierował jak to nazwać i pod jakim hasłem szukać, z resztą jakoś powoli sobie poradzę.
kluczowa fraza brzmi 'transparent http proxy' albo "transparent sockets proxy'..
Generalnie, bedziesz tutaj mial dwa problemy:
problem mniejszy brzmi - NIE WYSLESZ po http strumienia do uzytkownika w sposob aktywny. To uzytkownik musi wpierw sprobowac polaczyc sie z Twoja sciagarka/proxy, nie ona do niego.
Jak juz uda Ci sie miec w reku dwa polczenia - jedno do zrodla, drugie do odbiorcy - zakladam ze uzywasz socketow, ale moze byc to cokolwiek - cala reszta jest trywialna: tworzysz maly/sredni bufor w pamieci, np. char buf[1024] (chociaz dopasowany do wielkosci ramki bylby lepszy), i jak tylko blokujacy recv(socket_in, bufor, .., ...) czytajacy z oryginalnego zrodla sie wykona, natychmiast wykonuj send(socket_out, bufor, ..., ...), zamkniete w petli while:
unsigned char bufor[1024];
while(....)
{
recv(socket_in, bufor, ..., ...)
send(socket_out, bufor, ..., ...)
}
socket specific warning:
A) defaultowo sockety maja to do siebie, ze recv jest blokujacy, a send - nie. To znaczy, ze jedyne "spanie" odbywa sie na czekaniu na odbior paczki, a wypchniecie odebranej paczki jest natychmiastowe i od razu przechodzi sie do czekania na nastepna partie danych.. Odbierasz partiami po 1kB lub troche wiekszymi, wiec przestojow zwiazanych z czekaniem na zapelnienie bufora raczej nie bedzie.
B) specyfika send/recv jest jednak wredniejsza, i one, uwaga, wcale nie musza wyslac/odebrac tylu danych ile im nakazales, i nie oznacza to bledu albo zerwania polaczenia. nalezy za kazdym odpaleniem send czy recv sprawdzac ile pracy faktycznie wykonaly i jesli sie zdarzy ze wysla/odbiora mniej niz mialy - musisz sobie z tym nalezycie poradzic recznie. powyzszy dwulinijkowy "kod" wewnatrz while moze dzialac, ale nie musi. Aby dziala na pewno, musisz go rozbudowac o przynajmniej jeszcze jedna petle wokol send i kilka zmiennych pamietajacych pozycje w buforze.
Dzięki Ci bardzo :) o coś takiego mi chodziło :)
OK, więc tak... napisanie programu rzeczywiście okazało się dość trywialne, ale pojawił się nowy problem. Cała sytuacja wygląda w ten sposób: