Sprawdź, czy gniazdo jest zamknięte w bashu?

Question

Mam deskryptor pliku, który wskazuje na gniazdo (przykładowy kod poniżej).

exec 3<>/dev/tcp/localhost/9999 
echo -e "Some Command\n" >&3 

Czasami gniazdo zamyka się i należy je ponownie otworzyć (ponowne uruchomienie serwera).

Jak mogę sprawdzić, czy gniazdo (fd # 3 w tym przypadku) jest zapisywalne?

Echo zawsze się powiedzie, niezależnie od tego, czy gniazdo zostało już zamknięte, czy nie.

Answer 1

Rozwiązanie to informacja zwrotna od serwera.

Po wysłaniu żądania do serwera musi on odpowiedzieć.

exec 3<>/dev/tcp/localhost/9999 
echo -e "Some Command\n" >&3 
sleep 5 # example max time given to server to respond 
cat <&3 #receive an answer 
check is correct, restart server otherwise 

EDIT: użyciu netcata aby określić to port jest otwarty

netcat -w 3 -z www.google.com 80 
if[ $? -eq 0 ] 
then 
    echo port open 
else 
    echo port closed 
fi 

Answer 2

Można użyć komendy netstat, grep do portu/adresu, który chcesz, a następnie cut tylko pole stan. Należy pamiętać, że gniazdo może wyglądać jak "ESTABLISHED" przez pewien czas po utracie połączenia, szczególnie jeśli nie wysyłasz do niego żadnych danych.

Answer 3

Spróbuj napisać do fd:

pamiętać, że nie sugeruję zapisywania danych zbędnych aby sprawdzić, czy deskryptor jest nadal ważna, ale sugeruję, że jesteś po prostu staramy się pisać co dane chcesz, a następnie sprawdź, czy zadziałało. Jeśli zapis nie powiódł się, otwórz ponownie gniazdo i napisz ponownie.

Answer 4

dodam moje własne rozwiązanie ostateczne (w zwięzłej psudo-kod):

{ while true; 
    read file; 
    write to STDOUT } | 
{ while true; 
    netcat command; 
    write STDIN to buffer when/if netcat exits; 
    loop to restart netcat & first process buffered data if exists; } 

ten oddziela wyjście danych (odczyt z pliku) oraz przetwarzania danych (wysyłanie go do gniazdo lub buforowanie do pliku, gdy żadne gniazdo nie jest dostępne). Używa potoku do zapewnienia tymczasowego bufora, gdy występują problemy z siecią.

STDIN drugiego bloku kodu powoduje buforowanie wyjścia z pierwszego bloku kodu. Jeśli netcat nie jest w stanie przetworzyć danych na stdin, zdecyduje się zapisać to w pliku buforowym i spróbować ponownie uruchomić netcata. W ten sposób nie masz czasu między sprawdzeniem, czy to gniazdo jest otwarte (coś, co wciąż jest trudne), a faktycznym zapisem (który może nadal zawieść po sprawdzeniu, czy jest otwarty).

Answer 5

Minęło trochę czasu, odk op opublikowali to, aby mogli tego nie widzieć, ale może pomóc komuś innemu.

W każdym razie szukałem tego problemu i znalazłem następujące.

Otwarte pliki fd (deskryptory plików) procesu są wymienione w/proc // fd.

exec 3<>/dev/tcp/localhost/9999 

#check if still connected 
if [ $(ls /proc/$$/fd | grep -w "3") == 3 ]; then 
    #send data 
    echo -e "Some Command\n" >&3 
else 
    #perform reconnect 
    exec 3<>/dev/tcp/localhost/9999 
fi 

To nie było testowane, ale powinno być w większości w porządku. Może być też kilka ulepszeń. Jest też okno, w którym fd odchodzi pomiędzy czekiem a pisaniem na fd. Dotyczy to jednak wszystkich dotychczasowych rozwiązań.