Jak zorganizować rozległy monitoring IP z kamerami w kilkuset lokalizacjach?

Mam pytanie do bardziej doświadczonych kolegów i koleżanek.

Chodzi bardzo rozległy system monitoringu (kilkaset lokalizacji docelowo) w której będzie po 1 kamerce IP.
Kamerki maja za zadanie monitorować jedno pomieszczenie (maksymalnie kilka minut nagrania dziennie).
Wszystko będzie nagrywane na kartach pamięci w kamerze a dodatkowo strumień/zdjęcia poglądowe ma trafiać do centrali.
I teraz pytanie jak to rozwiązać?
Mi przychodzi do głowy rozwiązanie: serwer FTP w centralnej lokalizacji i zrzuty zdjęć 1kl/sek.
Czy ktoś ma jakieś inne ciekawsze pomysły?

Oprogramowanie monitoringu z wbudowanym serwerem FTP.
Sposób komunikacji ustawiasz w zależności od właściwości posiadanego łącza w lokalizacji kamery.
Tam gdzie można przekierować porty, konfigurujesz kamerę w klasyczny sposób.
Tam, gdzie porty zablokowane, używasz wysyłania na FTP.
Zaletą jest to, że bez względu na konfigurację, dostęp online i przeglądanie zapisów jest zawsze identyczne, z jednego programu monitoringu zainstalowanego w centrali.

A podasz przykład takiego oprogramowania na taka ilość kamer (kilkaset)?

Inne rozwiązanie np: Kamery IQeye lub axis + oprogramowanie exacq edge https://exacq.com/products/exacqvision_edge.html

basman123 napisał:

A podasz przykład takiego oprogramowania na taka ilość kamer (kilkaset)?

Od strony oprogramowania technicznie nic nie stoi na przeszkodzie aby podlinkowac do aplikacji kilkaset adresów kamer. Mówie o stronie technicznej, bo wiadomo fizycznie producenci robią ograniczenia do konkretnej ilości obsługiwanych kamer wzgledem wykupionej licencji. Praktyczny problem zaczyna się od strony fizycznej maszyny która ma mieć tak dużą moc obliczeniową.
Pozostaje Ci rozbicie kamer na grupy, oraz farma serwerów je obsługujących. Na kazdym serwerze identyczna aplikacja rejestrująca, a do obsługi aplikacja kliencka łącząca się z serwerami. Nic strasznego nie kombinujesz, normalny monitoring rozproszony tyle, że w większej skali.
Praktycznie większość dostępnych płatnie aplikacji spełni Twoje oczekiwania, nalezy jedynie rozpatrzyc kompatybilność wybranego softu z instalowanymi kamerami itp.
Nie napisałeś o wielu istotnych czynnikach, przy tak dużym projekcie istotne są wszystkie szczegóły, np rodzaj łącz dostępowych w lokalizacjach zdalnych, wymagana jakość nagrań/zdjęć per kamera, dostępność uslugi itp, itd.

basman123 napisał:

A podasz przykład takiego oprogramowania na taka ilość kamer (kilkaset)?

Użyj Google do wyszukania programów z wbudowanym serwerem FTP.
Oprogramowanie Selcamnet ma tę funkcję i w systemie klastrowym może obsługiwać kilkaset kamer.
Wydaje mi się, że większym problemem może być "ogarnięcie" takiej ilości kamer w sensie organizacyjnym.
Jakieś sensowne grupowanie, sortowanie, wyszukiwanie według lokalizacji itp.

Panowie rejestrator na linuxie z oprogramowaniem zoneminder i po klopocie tylko dobre łacze na centrum.
Jak cos służe pmocą

axis + milestone
axis + exacq

Podeślij dokładne wytyczne na PW to postaram się zaproponować jakieś konkretne rozwiązanie - informacja o dostępnym budżecie też będzie pomocna

wampirek napisał:

Panowie rejestrator na linuxie z oprogramowaniem zoneminder i po klopocie tylko dobre łacze na centrum.
Jak cos służe pmocą

Czy ten zoneminder ma jakieś ograniczenia co do ilości kamer, czy montuje się je w systemie ?

Ja na nim miałem okazję postawić 76 kamer raczej ograniczeń jako takich nie ma. Ograniczeniem systemu jest łącze internetowe centrum monitorowania. Jeśli potrzebna pomoc zapraszam na priv. Chetnie pomoge w konfiguracji i instaacji. Kamerki dodaje sie po adresie ip i porcie jak już.
Stawiałem go na linuxie ubuntu server 12.04 LTS

Jest jeszcze Avigilon, który wspiera tyle kamer, ile uciągnie komputer. Lista zgodności też dość szeroka:
http://avigilon.com/#/support-and-downloads/for-software/supported-cameras-and-encoders/

Dzięki wielkie, dam znać w wątku jak się sprawy potoczyły.

Jest jeszcze jedno rozwiązanie ale stosunkowo mało profesjonalne. Wspominałem tu, że ostatnio pojawiły się stosunkowo tanie urządzenia z Androidem w formie dongla HDMI.
Można do takiego urządzenia podłączyć przez USB kamerę np. Full HD z autofocusem. Taki komplet kosztuje około 500 zł. Po zainstalowaniu odpowiedniej aplikacji całość wysyła obrazki przez HTTP. Mogą być one w prosty sposób obierane przez skrypt PHP. Protokół HTTP jest znacznie szybszy niż FTP. Oczywiście nie uda się w ten sposób przesłać 25 klatek na sekundę ale 1 fps uzyskuje się bez problemu. Nawet mało wydajny komputer z zainstalowanym serwerem Apache może obsłużyć dużą ilość kamer.
Napisałem na własne potrzeby odpowiednią aplikację. Nie jest jeszcze skończona ale już działa. Dostępna tu: http://tvandroid.pl/CameraHTTP.apk
Przykładowy skrypt PHP do odbierania obrazków: http://tvandroid.pl/up.txt

Ale ten program co kolega mówi jest pod Windowsa a zone minder pod linuxa ciekawe co lepsze w tym przypadku jeśli bierzemy pod uwagę stailność całego systemu?? Ja skłaniałbym sie do pingwina

Padło wiele różnych propozycji, tylko chyba żadna nie zapewnia komunikacji z kamerą na każdym łączu internetowym.
Wbudowany w program monitoringu serwer FTP lub emulator tego serwera daje możliwość wykorzystania funkcji kamery wysyłania na FTP i przechwytywanie tego obrazu.
Może się mylę?

Totoya napisał:

axis + milestone
axis + exacq

Jak te programy obsługują przechwytywanie klatek protokołem FTP?
Konkretnie, kamerę konfiguruję do wysyłania protokołem FTP, program "odbiera" te klatki tak jak przy klasycznym pobieraniu obrazu z kamery.

wampirek napisał:

Panowie rejestrator na linuxie z oprogramowaniem zoneminder i po klopocie tylko dobre łacze na centrum.
Jak cos służe pmocą

Jak to działa w Zoneminder? Ma wbudowany emulator serwera FTP? Dawno się tym nie bawiłem.

iZabezpieczenia napisał:

Jest jeszcze Avigilon, który wspiera tyle kamer, ile uciągnie komputer. Lista zgodności też dość szeroka:
http://avigilon.com/#/support-and-downloads/for-software/supported-cameras-and-encoders/

Przejrzałem manual i nie widzę tej możliwości? Jeżeli jest, to może opisz w kilku zdaniach lub podpowiedz, gdzie tego szukać?

Pawel2420 napisał:

Jest jeszcze jedno rozwiązanie ale stosunkowo mało profesjonalne. ... Protokół HTTP jest znacznie szybszy niż FTP. ...

Rozwiązanie ciekawe, ale nie gwarantujące stabilnej pracy.
Protokół HTTP nie jest wcale szybszy od FTP. Nagłówek wysyłany protokołem HTTP jest zwykle dużo większy od ilości danych podczas negocjacji FTP. Jeżeli program monitoringu ma wbudowany emulator FTP to wszystko odbywa się dużo szybciej niż przy klasycznym FTP. Emulator nie wykonuje żadnych komend związanych z obsługą dysku, nazwami, ścieżkami itp. Celem jest tylko przechwycenie klatki w formacie jpg i przekazanie do dalszej "obsługi" w programie monitoringu. Ograniczeniem jest tylko łącze i możliwości samej kamery.

"Enterprise

Includes advanced features making it the most powerful, open HD surveillance platform around. Supports up to an unlimited number of cameras and servers for large-scale needs.

Standard

A cost-effective solution to meet vital and focused security needs. Supports up to 72 cameras and 3 server connections, making it an ideal solution for mid-size operations."

To wersje oprogramowania. Jest jeszcze do małych aplikacji wersja Core.

iZabezpieczenia napisał:

"Enterprise

Includes advanced features making it the most powerful, open HD surveillance platform around. Supports up to an unlimited number of cameras and servers for large-scale needs.

Standard

A cost-effective solution to meet vital and focused security needs. Supports up to 72 cameras and 3 server connections, making it an ideal solution for mid-size operations."

To wersje oprogramowania. Jest jeszcze do małych aplikacji wersja Core.

A gdzie tu jest o emulacji serwera FTP i możliwości przechwytywania klatek wysyłanych tym protokołem?

Wszelkie Axisy odpadają bo przy tylu lokalizacjach koszty byłby straszne.
Jeżeli chodzi o transmisję to serwer FTP nie jest niezbędny.
Jeżeli któryś program oferuje coś ciekawszego to nie ma problemu.
Tylko, że żeby nie zapychać niepotrzebnie łącza w centrum kamery nie mają mieć podglądu na stałe tylko podgląd ad-hoc a nagrywanie w centrum tylko po wykryciu detekcji ruchu (opcja kamery ze zrzutem serii zdjęć na serwer FTP).

basman123 napisał:

Wszelkie Axisy odpadają bo przy tylu lokalizacjach koszty byłby straszne.

Nie podałeś żadnych wymagań w stosunku do kamer.
Jakie warunki pracy, oświetlenie, rozdzielczość itp.?
Jak często będzie ten spodziewany ruch?
Co to za obiekt do monitorowania?
Są oczywiście tańsze rozwiązania, ale brak informacji do dobrania odpowiedniej kamery.

basman123 napisał:

Jeżeli chodzi o transmisję to serwer FTP nie jest niezbędny. ...Tylko, że żeby nie zapychać niepotrzebnie łącza w centrum kamery nie mają mieć podglądu na stałe tylko podgląd ad-hoc a nagrywanie w centrum tylko po wykryciu detekcji ruchu (opcja kamery ze zrzutem serii zdjęć na serwer FTP).

Nagrywanie z detekcji ruchu to funkcja wszystkich liczących się programów monitoringu. Z tym serwerem FTP sam sobie zaprzeczasz albo ja czegoś nie rozumiem.
Spróbuję to podsumować.
Jeżeli we wszystkich lokalizacjach będzie łącze internetowe bez blokady portów wejściowych, z możliwością przekierowania portów i najlepiej na stałym publicznym IP, to nie ma problemu. Każdy profesjonalny program monitoringu da sobie radę z podglądem online i rejestracją w przypadku wykrycia ruchu.
Jeżeli w któryś lokalizacjach te warunki nie będą spełnione i nie chcesz do kamery dokładać komputera, pozostaje wykorzystać protokół FTP, zarówno do podglądu online i jednocześnie do archiwizacji z detekcji ruchu. Protokół nie oznacza koniecznie serwera FTP, wystarczy emulacja tego serwera przez oprogramowanie monitoringu w centrali. Ta funkcja jest rzadko spotykana w oprogramowaniu monitoringu.
Jak możesz, napisz coś więcej o zastosowaniu tego monitoringu.
Jakie są konkretne wymagania? Czy te kilka minut na dobę z kamery będzie w tym samym czasie, czy rozłoży się równomiernie np.w ciągu ośmiu godzin?
A może kamery będą w ciągu doby włączane na kilka minut?

wampirek napisał:

Ja na nim miałem okazję postawić 76 kamer raczej ograniczeń jako takich nie ma. Ograniczeniem systemu jest łącze internetowe centrum monitorowania. Jeśli potrzebna pomoc zapraszam na priv. Chetnie pomoge w konfiguracji i instaacji. Kamerki dodaje sie po adresie ip i porcie jak już.
Stawiałem go na linuxie ubuntu server 12.04 LTS

Opowiedz proszę o maszynie na jakiej to stoi i konfiguracji samego ZM, generalnie ilość fps/kam, rozdzielczość oraz rodzaj nagrywania ciągłe czy tylko detekcja. Samo Ubuntu potrzebuje dużo zasobów o obróbce video już nie wspomnę, stąd pytanie.

Marek31415 napisał:

Jak to działa w Zoneminder? Ma wbudowany emulator serwera FTP? Dawno się tym nie bawiłem.

Raczej wątpie, też dawno nie zaglądałem, można napewno odpalić ftp'a ale do pobierania zdjęć lub nagrań już zapisanych, wkońcu to nie rzadna sztuka odpalić ftp'a...
Generalnie moje zdanie jest takie że ZM do sie nadaje do domu jak ktos lubi konsole i zabawe z linuxem, ale nie w produkcyjnym zastosowaniu dla klientów. Z różnych względów.

A tak BTW to ftp z natury jest protokołem szybszym od http.

Procesor AMD PHENOM 4x 9650 płyta MSI 2 dyski twarde po 2 TB i oczywiście LAn 1 GBit
A na linuxie server ftp mozesz odpalic w kazdej chwili tylko jaki ma sens wysyłanie orazu po ftp. zone minder bazuje na streemingu odbiera w zależności od kamery obra mjpeg h264 itp.
System pracuje bardzo stabilnie.
Pozatym zm konfiguruje sie nie z konsoli tylko spod przeglądarki i znajduje on wiele zastosowan w profesjonalnych systemach monitoringu.
Co do parametrów to kazda z kamer pracowała z prędkością 15kl/s o rozdzielczości 1,3Mpix

Marek31415 napisał:

Nagrywanie z detekcji ruchu to funkcja wszystkich liczących się programów monitoringu. Z tym serwerem FTP sam sobie zaprzeczasz albo ja czegoś nie rozumiem.
Spróbuję to podsumować.
Jeżeli we wszystkich lokalizacjach będzie łącze internetowe bez blokady portów wejściowych, z możliwością przekierowania portów i najlepiej na stałym publicznym IP, to nie ma problemu. Każdy profesjonalny program monitoringu da sobie radę z podglądem online i rejestracją w przypadku wykrycia ruchu.
Jeżeli w któryś lokalizacjach te warunki nie będą spełnione i nie chcesz do kamery dokładać komputera, pozostaje wykorzystać protokół FTP, zarówno do podglądu online i jednocześnie do archiwizacji z detekcji ruchu. Protokół nie oznacza koniecznie serwera FTP, wystarczy emulacja tego serwera przez oprogramowanie monitoringu w centrali. Ta funkcja jest rzadko spotykana w oprogramowaniu monitoringu.

Wszystko ok. Tylko powiedz mi skąd szanujące oprogramowanie ma wiedzieć, że ma nagrywać z wideodetekcji? Bo ja nie wyobrażam sobie sytuacji, że kilkaset kamer cały czas nadaje bo łącze w centralnym punkcie obawiam się że by uklęknęło.
Dzięki serwerowi FTP (funkcja kamery) mamy możliwość taką, że łączę w centrali jest zajmowane tylko w momencie kiedy jest ruch w kamerze, ewentualnie połączenie ad-hoc w celu sprawdzenia czy wszystko jest ok z kamerą.
Czyli najlepsze rozwiązanie to jest to o którym mówisz z emulacją serwera FTP, tak mi się wydaje.

Jeżeli chodzi o dobór kamer to z tym nie mam problemu (będą to kamerki 1MPix) z doświetleniem. Bardziej mi chodziło o rozwiązanie zapisu z takich kamer.

basman123 napisał:

Bo ja nie wyobrażam sobie sytuacji, że kilkaset kamer cały czas nadaje bo łącze w centralnym punkcie obawiam się że by uklęknęło.

To masz małą wyobraźnię. Zakładając tak jak wspomniałeś na początku 1 fps z kamery i wielkość obrazka na poziomie 100kB to dla 100 kamer potrzebne będzie do serwera łącze o przepustowości 100Mbps. Obecnie np. w https://www.ovh.pl/ łącze 1Gbps jest już w zasadzie standardem.

Tak jak napisałem wcześniej protokół FTP jest jednak stosunkowo wolny. Kamera za każdym razem wysyłając obrazek wykonuje logowanie. Przed wysłaniem rozkazu zapisu pliku musi otrzymać potwierdzenie wykonania poprzednich operacji. Przesłanie obrazka wymaga też nawiązania dwóch połączeń TCP. Wszytko to zajmuje czas. W przypadku HTTP nawiązane jest tylko jedno połączenie TCP i od razu wysyłanie są dane. Należy również wspomnieć, że serwery są zoptymalizowane pod kątem jednoczesnego obsługiwania dużej ilości połączeń HTTP. W przypadku FTP tak nie jest. Niestety w zasadzie nie ma kamer potrafiących przesyłać obraz przez HTTP np. poleceniem POST.

basman123 napisał:

Wszystko ok. Tylko powiedz mi skąd szanujące oprogramowanie ma wiedzieć, że ma nagrywać z wideodetekcji? Bo ja nie wyobrażam sobie sytuacji, że kilkaset kamer cały czas nadaje bo łącze w centralnym punkcie obawiam się że by uklęknęło.
Dzięki serwerowi FTP (funkcja kamery) mamy możliwość taką, że łączę w centrali jest zajmowane tylko w momencie kiedy jest ruch w kamerze, ewentualnie połączenie ad-hoc w celu sprawdzenia czy wszystko jest ok z kamerą.
Czyli najlepsze rozwiązanie to jest to o którym mówisz z emulacją serwera FTP, tak mi się wydaje.

Wystarczy ustawić w kamerce wysyłanie z detekcji ruchu, dodatkowo np. co minutę klatkę z timer-a.
Program może dodatkowo sprawdzać ruch w otrzymanym materiale. Detekcja w kamerze często nie działa idealnie i wysyła zbyt dużo.
Klatka co minutę zastąpi połączenie bezpośrednie i umożliwi kontrolę działania kamery.
Emulacja serwera FTP przy tej ilości kamer jest najlepszym rozwiązaniem.
Materiał ze wszystkich kamer jest zapisywany w formacie strumieniowym, uporządkowany, niewymagający dalszej obróbki.
Czyli dokładnie tak, jak w przypadku kamery podłączonej w sieci lokalnej lub zdalnej w sposób standardowy.
Jeżeli będzie możliwość podłączenia standardowego do kamery, to w opisywanym oprogramowaniu jest jeszcze jedna przydatna funkcja, podłączenie DEMO do kamery. Polega to na tym, że strumień z kamery jest pobierany wyłącznie w momencie zdalnego podglądu przeglądarką internetową z wbudowanego w program serwera WWW. Rozwiązuje to problem zdalnej kontroli pracy kamery, podglądu online przy jednoczesnym nie obciążaniu łącza w pozostałym czasie.
Jest jeszcze możliwość aktywowania "normalnego" pobierania strumienia w momencie detekcji ruchu w kamerze i przesłanie pierwszej klatki przez FTP lub sygnalizacji ruchu przez TCP (niektóre kamery mają taką możliwość).
Ta technika rozwiązuje problem obciążenia łącza w centrum monitoringu. Możliwości jej wykorzystania musisz sprawdzić u producentów programów. Przy zakupie licencji na tak dużą ilość kamer nie powinno być problemu.

Zapominacie panowie o protokóle RTSP oraz ONVIF właśnie stad oprogramowanie wie kiedy następuje ruch. FTP ok ale weżmy pod uwagę jedną rzecz dosyć prostą ftp ma ograniczenia co do ilości sessji jednoczesnych pozatym w stosunku do w/w jest naprawde wolny. Zastanówcie sie pierw jak rozlegly ma byc to system i jaką ilość kamer ma obsłużyć. Pozatym jaki nie był by to protokół to nie zwalnia nas z tego że łącze na centrum monitorowania musi mieć minimum te 100 Mbit/sec. Pozatym protokół ftp bardziej obciąża łącze niż te co w/w. Pozatym istnieje jeszce kompresja h.264.

wampirek napisał:

Zapominacie panowie o protokóle RTSP oraz ONVIF właśnie stad oprogramowanie wie kiedy następuje ruch.

RTSP to tylko jeden ze sposobów przesyłania dodatkowych informacji, w tym wypadku na oddzielnym porcie UDP. Przy rozległym monitoringu i konieczności przekierowania portów, często losowym przydziale portów UDP to tylko komplikuje temat.
ONVIF nie jest tu żadnym lekarstwem lecz standaryzacją pewnych, od dawna istniejących mechanizmów.

wampirek napisał:

FTP ok ale weżmy pod uwagę jedną rzecz dosyć prostą ftp ma ograniczenia co do ilości sessji jednoczesnych pozatym w stosunku do w/w jest naprawde wolny.

FTP nie ma tu żadnych ograniczeń, ograniczenia są wprowadzane w konkretnych programach implementujących FTP. I nie jest wcale wolny, jest jednym z najszybszych protokołów.

wampirek napisał:

Zastanówcie sie pierw jak rozlegly ma byc to system i jaką ilość kamer ma obsłużyć. Pozatym jaki nie był by to protokół to nie zwalnia nas z tego że łącze na centrum monitorowania musi mieć minimum te 100 Mbit/sec.

Chyba nieuważnie czytasz. Przy proponowanym rozwiązaniu nie ma szczególnych wymagań w stosunku do łącza.

wampirek napisał:

Pozatym protokół ftp bardziej obciąża łącze niż te co w/w. Pozatym istnieje jeszce kompresja h.264.

Bardzo się mylisz. Jest dokładnie odwrotnie. Zapoznaj się ze sposobem zestawiania połączenia i wymiany informacji protokołem FTP. Chyba pomyliłeś z SMTP. Ten jest najwolniejszy.

Marek31415 napisał:

RTSP to tylko jeden ze sposobów przesyłania dodatkowych informacji, w tym wypadku na oddzielnym porcie UDP. Przy rozległym monitoringu i konieczności przekierowania portów, często losowym przydziale portów UDP to tylko komplikuje temat.

Mylisz się. W przypadku RTSP over UDP pomocnicze informacje przesyłane są przez TCP. Właściwy obraz/dźwięk jest transmitowany przez UDP. Połączenie TCP w wielu przypadkach potrzebne jest jedynie na początku w fazie negocjacji. Później może być zamknięte. Co więcej transmisja obrazu przez UDP jest akurat bardzo wygodna do stosowania w rozległych sieciach a odbieranie danych z wielu kamer jednocześnie wymaga znacznie mniej zasobów niż w przypadku TCP.

Pawel2420 napisał:

Mylisz się. W przypadku RTSP over UDP pomocnicze informacje przesyłane są przez TCP.

Nie jest to tematem tego wątku.
Po negocjacji na domyślnym porcie komend, TCP 554 (może być inny), są otwierane dwa porty UDP, jednym przesyłany jest strumień np. obraz, dźwięk. A drugim ...
Port komend nigdy nie jest zamykany. Z dwóch podstawowych powodów, po pierwsze zakończenie odbioru strumienia powinno być zasygnalizowane komendą TEARDOWN, po drugie przeważnie strumień jest wysłany przez określony czas, np. 30 sekund i kamera wymaga odnowienia żądania dalszej wysyłki.
W zależności od samej kamery dodatkowe informacje są przesyłane w nagłówku pakietu strumienia, w samym strumieniu, na drugim otwartym porcie UDP.
Nie spotkałem się natomiast z przesyłaniem tych informacji portem komend.
Programowałem moduł odbioru strumienia RTP/RTSP od podstaw, znam każdy bajt tego protokołu. Możemy podyskutować, ale raczej nie w tym wątku.

I tu sie zgodze zkolega Pawłem Ftp jest jednym z wolniejszych protokołów i także wymaga przekierowanie portu na serwerze rejestrujacym to pierwsze poza tym losowo nie moze on przydzielac na jakim porcie chodzi tylko ustawia go instalator wiec kolego proponuje doczytac troszke bo mam w/w system na rtsp postawiony i smiag fajnie. Pozatym wielkosc systemu ma bardzo duze znaczenie.

wampirek napisał:

I tu sie zgodze zkolega Pawłem Ftp jest jednym z wolniejszych protokołów i także wymaga przekierowanie portu na serwerze rejestrujacym to pierwsze poza tym losowo nie moze on przydzielac na jakim porcie chodzi tylko ustawia go instalator wiec kolego proponuje doczytac troszke bo mam w/w system na rtsp postawiony i smiag fajnie. Pozatym wielkosc systemu ma bardzo duze znaczenie.

Też proponuję poczytać i czytać uważnie posty. Serwery FTP są wolne, bo administrator może ograniczyć łącze dla użytkownika. Sam protokół nie. Jest szybszy nawet od RTSP, bo nie fragmentuje pliku dołączając do każdego kilobajta (czasem kilku) nagłowek, tak ja w przypadku RTSP. Losowe przydzielanie portu dotyczyło UDP przy RTSP, nie FTP. A dyskusja dotyczyła emulatora serwera FTP w systemie monitoringu. Nie są tu prawdziwe wszystkie informacje dotyczące klasycznych serwerów FTP, w tym również o wielkości systemu.
Skończmy tę dyskusję, jest bez sensu.