Czy istnieje narzędzie przypominające ogon obsługujące WebDav

2

Moim problemem jest to, że zastrzeżona platforma SaaS, którą rozwijam na / for, udostępnia pliki dziennika tylko przez WebDav. Podczas opracowywania pliki dziennika mogą stać się dość duże do końca dnia (pomyśl 200 Mb +), ale są bardzo szczegółowe i przydatne, gdy próbujesz wyśledzić „błąd ogólny”.

Co się teraz ze mną dzieje, że aby spojrzeć na plik dziennika, muszę pobrać plik 200 Mb za każdym razem (nie zostanie automatycznie odtworzony, jeśli go usunę :(), co oznacza, że nawet przy dobrym połączeniu musisz poczekać 1 -2 minuty do pobrania pliku.

Tak więc aktualne pytanie: czy istnieje jakieś narzędzie, które może spojrzeć (na przykład) na sygnaturę czasową pliku co 5 sekund i po prostu pobrać dodaną porcję (używając obliczonej różnicy wielkości).

logging tail webdav

— KillerX
źródło

+1. Dobre pytanie. Pracuję nad sposobem szybkiego zsynchronizowania plików przez WebDAV z systemem klienckim i szukania w zsync. Przedstawiłem poniżej rozwiązanie wysokiego poziomu dla twoich wymagań.

— Kent Pawar,

1

WebDAV jest rozszerzeniem protokołu HTTP i obecnie dostępne metody [ 1 ] nie obsługują tego samego.
Możesz spojrzeć na alternatywne metody częściowego przesyłania plików przez HTTP, takie jak zsync , które przenoszą tylko zmienioną treść.

1. zsync

Streszczenie : W tym dokumencie opisano sposób myślenia zsync, nowego programu do przesyłania plików, który implementuje efektywne pobieranie tylko zawartości pliku, który nie jest jeszcze znany odbiorcy. zsync wykorzystuje algorytm rsync, ale zaimplementowany po stronie klienta, dzięki czemu na serwerze wymagane są tylko jednorazowe wstępne obliczenia, a do korzystania z zync nie jest wymagane żadne specjalne oprogramowanie serwera ani nowy protokół.

AKTUALIZACJA:

Zgodnie z algorytmem rsync:

Jedna strona oblicza sumy kontrolne każdego odrębnego bloku danych i przesyła je na drugi koniec. Drugi koniec następnie dokonuje kroczącej sumy kontrolnej poprzez swój plik, identyfikując wspólne bloki, a następnie ustalając, które bloki nie są wspólne i muszą zostać przesłane.
W rsync serwer wykonuje całą ciężką pracę, podczas gdy w zsync klient żądający danych wykonuje całą ciężką pracę polegającą na zastosowaniu ruchomej sumy kontrolnej rsync i porównaniu z pobraną listą sum kontrolnych.

Od [ 4 ]

... Stajemy się więc serwerem, który oblicza sumy kontrolne każdego odrębnego bloku. Ponieważ trzeba obliczyć tylko jedną sumę kontrolną na blok danych, a nie jest to specyficzne dla danego klienta, dane mogą być buforowane. Możemy zapisać te dane w metapliku, a klient żąda tych danych jako pierwszy krok procesu. Ten metaplik może po prostu znajdować się pod innym adresem URL na tym samym - lub nawet innym - serwerze.

Klient zsync pobierze ten metaplik. Następnie przegląda dane, które już posiada, stosując ruchomą sumę kontrolną rsync i porównując z pobraną listą sum kontrolnych. W ten sposób identyfikuje dane w pliku docelowym, który już ma. Następnie żąda pozostałych danych z serwera. Ponieważ wie, jakich danych potrzebuje, może po prostu użyć żądań zakresu HTTP, aby pobrać dane. ...

Dlatego nagłówki zakresu HTTP muszą być obsługiwane po stronie serwera.

2. Alternatywy dla zsync

Ale jeśli te pliki dziennika tylko wzrosną, a zatem istniejąca zawartość się nie zmieni Range, wystarczy nagłówek HTTP . [ 2 ] [ 3 ]

Odniesienie:

— Kent Pawar
źródło

Dzięki za zsync, spojrzę na to, to brzmi bardzo interesująco. Jeśli chodzi o zasięg: niestety serwer, z którym rozmawiam, nie obsługuje go: S (podobnie jak wiele innych rzeczy).

— KillerX

Proszę bardzo. ZsyncWymagałoby to jednak obsługi Rangenagłówków po stronie serwera. Zaktualizowałem swój post, aby go podświetlić.

— Kent Pawar,

1

Jeśli klient jest komputerem z systemem Windows, spróbuj tego: Zamapuj udział webdav jako dysk sieciowy i uruchom polecenie tail na pliku.

— Giri
źródło