.\" {PTM/RM//31-08-2000}
.\" Autor troche miesza w konwencji nazw klient|klient proxy|serwer|Serwer proxy
.TH DXPC 1 "19 sierpnia 1999" "dxpc"
.ad b
.SH NAZWA
\fBdxpc\fR - różnicowy kompresor protokołu X

.SH WERSJA
3.8.0

.SH SKŁADNIA
.BR dxpc
\fB[wspólne] [klient | serwer] [połączenie]\fR
.br

\fB[wspólne]\fR opcje:
.br
	-p \fInumer_portu\fR -f -k -v -s \fIpoziom_debugowania\fR -l \fIlog_file\fR
.br

\fB[klient]\fR opcje (dla procesu KLIENT-a):
.br
	-i \fIpoziom_kopresji\fR -d \fInumer_dispalya\fR -u
.br

\fB[serwer]\fR opcje (dla procesu SERWER-a):
.br
	-D \fIdisplay\fR
.br

\fB[połączenie]\fR opcje:
.br
	\fInazwa_hosta\fR -w
.SH OPIS
\fBdxpc\fR jest kompresorem protokołu X stworzonym w celu zwiększenia
szybkości "transmisji" aplikacji X11 uruchamianych przez wolne łącza (np.: 
telefoniczne połączenia PPP).
.sp
\fBdxpc\fR musi być uruchomiony po obu stronach łącza. Na jednym z hostów - 
gdzie pracuje rzeczywisty X serwer - \fBdxpc\fR pracuje w trybie "serwera proxy",
na drugim w trybie "klienta proxy". "Klient proxy" musi być uruchomiony 
jako pierwszy. W czasie startu "serwer proxy" nawiązuje połączenie 
z "klientem". (Zauważ, że wersje \fBdxpc\fR sprzed 3.3.1 używają odwrotnej
konwencji.) Kiedy jeden z procesów \fBdxpc\fR jest przerywany, drugi 
automatycznie wyłącza się również.
.sp
"Klient proxy" naśladuje X-serwer. Aplikacje X-klienta łączą sie 
z "klientem proxy" używając displaya "unix:8" (lub <nazwa_hosta>:8 ;
\fBdxpc\fR wspomaga zarówno domeny UNIX-owe jak i gniazda TCP). "Klient
proxy" przechwytuje wywołania X-owe od aplikacji, kompresuje je
i wysyła do "serwera proxy". "Serwer" dekompresuje je i przesyła
do rzeczywistego serwera X. Podobnie "serwer proxy" otrzymuje
zdarzenia, odpowiedzi i błędy od rzeczywistego X-serwera, kompresuje
i przesyła do "klienta proxy", który po dekompresji śle je do
aplikacji klienta.
.sp
Stopień kompresji \fBdxpc\fR zależy od typu aplikacji X-owej. Dla większości
aplikacji \fBdxpc\fR uzyskuje wyniki kompresji od 3:1 do 6:1.
.sp
.SH MODY PRACY
\fBdxpc\fR może pracować w jednym z dwóch stanów: stanie 
nawiązywania połączenia (\fInasłuchiwanie\fR lub \fIłączenie\fR) 
i stanie pracy w Systemie X (\fIklient\fR lub \fIserwer\fR). Każda sesja 
pracy w \fBdxpc\fR zawsze zaczyna sie od stanu nawiązywnia połączenia
po czym - jeżeli połączenie jest nawiązane - przechodzi do stanu
pracy w Systemie X.
.sp
\fINasłuchiwanie\fR oczekuje na inicjację połączenia TCP - między 
dwoma procesami - przez \fIłączenie\fR. \fINasłuchiwanie\fR musi być
zawsze uruchamiane jako pierwsze. \fIŁączenie\fR jest inicjatorem połączenie 
TCP
z \fInasłuchiwaniem\fR. \fBdxpc\fR startuje w trybie \fIłączenia\fR jeżeli
podany jest argument \fInazwa_hosta\fR (zobacz: opcje \fBpołączenie\fR, powyżej).
W innym przypadku startuje w trybie \fInasłuchiwania\fR.
.sp
Proces \fIserwera\fR jest zwykle umiejscowiony na tej samej maszynie,
na której pracuje rzeczywisty X-serwer i odpowiada za wyświetlanie
aplikacji, proces \fIklienta\fR
zaś na maszynie, gdzie jest uruchomiona aplikacja X i odpowiada on za
przekazywanie wyniku pracy aplikacji do procesu \fIserwera\fR.
Domyślna kolejność pracy \fBdxpc\fR jest następujaca: tryb \fInasłuchiwania\fR,
a po zestawieniu połączenia tryb \fIklienta\fR (jeżeli nie użyto argumentu 
\fInazwa_hosta\fR)
lub tryb \fIłączenia\fR, a po połączeniu tryb \fIserwera\fR. Opcja -w
zmienia ta kolejność (tj.: \fInasłuchiwanie\fR-\fIserwer\fR lub 
\fIłączenie\fR-\fIklient\fR).
.sp
Na przykład komenda \fBdxpc host.w_pracy.com\fR startuje \fBdxpc\fR w trybie
\fIłączenia\fR (ponieważ jest użyty argument \fInazwa_hosta\fR)
i potem \fIserwera\fR (bo opcja -w nie zostala użyta).
Komenda \fBdxpc -w\fR startuje \fBdxpc\fR w trybie \fInasłuchiwania\fR
(bo nie ma argumentu \fInazwa_hosta\fR) i potem \fIserwera\fR
(bo opcja -w zmienia standardowe wywolanie)
.sp
.SH Opcje
.TP 12
.B -d \fInumer_displaya\fR
Ustawia numer displaya, który \fBdxpc\fR imituje. Domyślnie \fBdxpc\fR przyjmuje
wartość 8 (opcja ignorowna w trybie "serwer proxy").

.TP 12
.B -f
Powoduje powielenie się (forkowanie) \fBdxpc\fR i start jako daemon. Drukowanie 
komunikatów na wyjście standardowe (poza błędami) jest wstrzymane, statystyki
również.
Proces daemona może być wyłączony przez (kolejne) użycie \fBdxpc\fR z opcją \
fB-k\fR.

.TP 12
.B -k
Powoduje przeczytanie numeru PID z pliku blokującego w katalogu domowym
użytkownika (~/.dxpc.pid-HOST-USER-PORT) i przesłanie sygnału SIGKILL do 
pracującego procesu \fBdxpc\fR. Plik blokujący istnieje jedynie jeżeli
\fBdxpc\fR zostało uruchomione z opcja \fB-f\fR.

.TP 12
.B -l \fIlog_file\fR
Z tą opcją \fBdxpc\fR zapisuje komunikaty i informacje statystyczne do 
pliku dziennika \fIlog_file\fR.
Opcja szczególnie użyteczna z \fB-f\fR.

.TP 12
.B -p \fInumer_portu\fR
Ta opcja ustawia port TCP, który będzie używany do komunikacji między
"klientem proxy" i "serwerem proxy". Wartość domyślna 4000.

.TP 12
.B -s(1|2)
Wyświetla raport o poziomie kompresji. W trybie "klienta proxy" \fBdxpc\fR
wypisuje raport o kompresji na podstawie komunikatów od X-klienta,
w trybie "serwera proxy" na podstawie komunikatów X-serwera.
Z opcją \fB-s1\fR \fBdxpc\fR informuje o poziomie kompresji w postaci
skróconej, z \fB-s2\fR w postaci szczegółowej. Większości użytkowników
z pewnością wystarczy opcja \fB-s1\fR.

.TP 12
.B "-u -t"
Normalnie \fBdxpc\fR w trybie "klienta proxy" imituje display :8 (zarówno
w przypadku gniazd TCP jak i domen UNIX-owych). Opcja \fB-u\fR
zabrania \fBdxpc\fR używania domen UNIX-owych, a \fB-t\fR gniazd TCP.
(Opcje są ignorowane w trybie "serwer proxy").

.TP 12
.B "-v"
\fBdxpc\fR z opcją \fB-v\fR wypisuje numer wersji, informacje o prawach autorskich
i kończy pracę.

.TP 12
.B "-w"
Odwraca kolejność "sluchania" i "inicjowania" w stanie nawiązywania połączenia.
Oznacza to, że klient będzie inicjował połączenia z serwerem.
W miejsce komend uruchamiających: klienta \fBdxpc -f\fR i serwera
\fBdxpc -f serwer.w_pracy.com\fR można użyć: \fBdxpc -w -f serwer.w_domu.priv\fR
- start klienta i \fBdxpc -w -f\fR - start serwera. Opcja \fB-w\fR
jest użyteczna dla startu "klienta proxy" za firewallem.

.TP 12
.B "nazwa_hosta"
Argument \fInazwa_hosta\fR musi być użyty w trybie "serwera proxy"
w celu identyfikacji maszyny (po nazwie bądź po adresie IP), na której
uruchomiony jest \fBdxpc\fR w trybie "klienta proxy". (Obecność tego argumentu 
implikuje start w trybie "serwera proxy", jego brak w trybie "klienta proxy").

.TP 12
.B "-D display"
Ustawia (display) hosta, na który przesyłane będą aplikacje X.
Domyślnie jest to zmienna środowiska DISPLAY. 

.TP 12
.B "-i(0..9|99|999)"
Kontrola kompresji bitmap. (Opcja \fB-i\fR może być używana na kliencie albo
- jeżeli podano opcje \fB-w\fR - na serwerze, w pozostałych przypadkach jest
ignorowana.) Numer odpowiada za poziom kompresji; wyższe poziomy dają lepszą
kompresję ale kosztem CPU i pamięci (głównie na "kliencie proxy").
Aktulna lista poziomów i typów kompresji jest podana ponizej.

0 : Bez kompresji (oprócz \fBdxpc\fR 3.7.0, gdzie daje bardzo słabą kompresję).

1 : kompresja LZO lzo1x_1; bardzo szybka, małe zużycie CPU, rozsądny poziom
kompresji.

2-9: kompresja LZO wariant lzo1c_n . lzo1c_2 wydaje sie być gorsza niż lzo1x_1.

99: kompresja LZO lzo1c_99. Wolna ale bardzo dobra kompresja. Zanotowano
niespodziewane błędy. Nie zalecana.

999: kompresja LZO lzo1x_999. Wolna (ale wystarczająco szybka dla połączeń 
128k ISDN, przy korzystaniu z Pentium II/300 nie używa - nawet chwilowo - pełnej mocy
procesora). Wartość domyślna i zalecana.


.SH PRZYKŁADY
W przypadku użycia rzeczywistego X-serwera na lokalnej maszynie (pc_w_domu)
i korzystania z aplikacji na zdalnym systemie (serwer.praca.com) wyświetlanych
na lokalnej maszynie. 
.sp
Na zdalnej maszynie serwer.praca.com 
.nf
    $ export DISPLAY=pc_w_domu:0 (sh lub bash)
lub $ setenv DISPLAY pc_w_domu:0 (csh lub tcsh)
    $ \fBdxpc\fR -f
    $ export DISPLAY=unix:8      (sh lub bash)
lub $ setenv DISPLAY unix:8      (csh lub tcsh)
.fi

Na lokalnej maszynie
.nf
    $ export DISPLAY=unix:0      (sh lub bash)
lub $ setenv DISPLAY unix:0      (csh lub tcsh)
    $ \fBdxpc\fR -f serwer.praca.com
.fi

Teraz znów na zdalnej maszynie
.nf
    $ xterm&
    $ xemacs&
    itd...
.fi

.SH "DXPC I XAUTH"
Jeżeli używasz autoryzacji X z plikiem .Xauthority na lokalnej maszynie,
gdzie pracuje rzeczywisty X-serwer powinieneś dostosować plik .Xauthority 
na maszynie, gdzie \fBdxpc\fR jest uruchomione w trybie "klienta proxy".
Jedną z dróg do tego prowadzących jest: 
 .sp
Skopiowanie pliku ~/.Xauthority z lokalnej maszyny na zdalną (gdzie
jest "klient proxy").
 .sp
Wydanie polecenia
.nf
    $ \fBxauth\fR list
.fi
w celu obejrzenia kluczy autoryzacyjnych. Jedna z linijek
w wydruku powinna zawierać Twój display X i wyglądać podobnie do:
.nf
    <Twoj_host>/unix:0   MIT-MAGIC-COOKIE-1   <HEX>
.fi
Na maszynie, na której pracuje "klient proxy" należy "dodać" tę linię
do pliku .Xauthority, ale z "oszukanym" X-displayem (DISPLAY
z serwera, gdzie "klient proxy" nasłuchuje). Opcja "add"
komendy \fBxauth\fR realizuje to następująco
.nf
    $ \fBxauth\fR add <host>/unix:8 MIT-MAGIC-COOKIE-1  <HEX>
.fi
gdzie <host> jest nazwą maszyny, gdzie jest uruchomiony "klient proxy".
Po wykonaniu tego polecenia powinno być możliwe bezproblemowe używanie \fBdxpc\fR.
.sp
Uwaga: W przypadku połączeń przez slogin (ssh) wydruk z komendy
.nf
    $ \fBxauth\fR list
.fi
może być inny. Warto przed podaniem w/w komendy skorzystać z
.nf
    $ echo $DISPLAY
.fi

.SH AUTOR
Brian Pane

.SH POMOC
Kevin Vigor (kevin@vigor.nu)

.SH PODZIĘKOWANIA
\fBdxpc\fR zaadoptowało wiele koncepcji z systemu \fBHBX\fR i \fBFHBX\fR
 (http://www.cs.dartmouth.edu/~jmd/decs/DECSpage.html).
.sp
Dziekuję wszystkim użytkownikom, którzy przesyłali sugestie i uwagi.

.SH ZOBACZ TAKŻE
xauth(1), plik README z dytrybucji dxpc.

.SH OD TŁUMACZA
Dodano kilka słów w sekcji \fBPRZYKŁADY\fR.
