Sztucznie twórz błąd przekroczenia limitu czasu połączenia

Mam błąd w naszym oprogramowaniu, który pojawia się, gdy otrzymuję limit czasu połączenia. Te błędy są bardzo rzadkie (zwykle, gdy moje połączenie zostaje przerwane przez naszą sieć wewnętrzną). Jak mogę sztucznie wygenerować taki efekt, aby przetestować nasze oprogramowanie?

Jeśli ma to znaczenie, aplikacja jest napisana w C ++ / MFC przy użyciu klas CAsyncSocket.

Edytować:

Próbowałem użyć nieistniejącego hosta i pojawia się błąd gniazda:

WSAEINVAL (10022) Niepoprawny argument

Następną moją próbą było skorzystanie z sugestii Aleksandra , aby połączyć się z innym portem, np. 81 (choć na moim własnym serwerze). To działało świetnie. Dokładnie to samo co zerwane połączenie (60 sekund oczekiwania, potem błąd). Dziękuję Ci!

Połącz się z istniejącym hostem, ale z portem zablokowanym przez zaporę, która po prostu upuszcza pakiety TCP SYN. Na przykład www.google.com:81.

Połącz się z niemożliwym do routingu adresem IP, takim jak 10.255.255.1.

Jeśli korzystasz z komputera z systemem uniksowym, możesz rozpocząć nasłuchiwanie portu za pomocą netcat:

nc -l 8099

Następnie zmodyfikuj usługę, aby wywoływała to, co zwykle robi z tym portem, np. Http: // localhost: 8099 / some / sort / of / endpoint

Następnie twoja usługa otworzy połączenie i zapisze dane, ale nigdy nie otrzyma odpowiedzi, a więc da ci limit czasu na odczyt (zamiast odmowy połączenia)

Poniższy adres URL zawsze podaje limit czasu i łączy najlepsze z powyższych odpowiedzi @Alexander i @ Emu:

http://example.com:81

Użycie example.com:81jest ulepszeniem odpowiedzi Aleksandra, ponieważ example.com jest zarezerwowany przez standard DNS, więc zawsze będzie niedostępny, w przeciwieństwie do tego google.com:81, co może się zmienić, jeśli Google ma na to ochotę. Ponadto, ponieważ example.comjest zdefiniowany jako nieosiągalny, nie zalejesz serwerów Google.

Powiedziałbym, że to poprawa w stosunku do odpowiedzi @ emu, ponieważ jest o wiele łatwiejsza do zapamiętania.

Wiele dobrych odpowiedzi, ale najczystszym rozwiązaniem wydaje się ta usługa

http://httpstat.us/504?sleep=60000

Możesz skonfigurować czas oczekiwania (do 230 sekund) i ewentualny kod powrotu.

Za pomocą Python REPL można symulować przekroczenie limitu czasu podczas odbierania danych (tj. Po pomyślnym nawiązaniu połączenia). Nie jest wymagana tylko standardowa instalacja w języku Python.

Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)        
>>> s.bind(('localhost', 9000))
>>> s.listen(0)
>>> (clientsocket, address) = s.accept()

Teraz czeka na połączenie przychodzące. Połącz wszystko, co chcesz przetestować localhost:9000. Gdy to zrobisz, Python zaakceptuje połączenie i accept()je zwróci. O ile nie prześlesz żadnych danych przez clientsocket, gniazdo dzwoniącego powinno przekroczyć limit czasu podczas następnego recv().

• 10.0.0.0
• 10.255.255.255
• 172.16.0.0
• 172.31.255.255
• 192.168.0.0
• 192.168.255.255

Wszystkie te są nierutowalne.

Chciałbym zwrócić uwagę wszystkich na pathod

Dzięki konfiguracji (wziętej z ich przykładów) 200:b@100:drotrzymasz połączenie, które losowo znika.

Co powiesz na rozwiązanie programowe:

Zainstaluj serwer SSH na serwerze aplikacji. Następnie użyj tunelu gniazda, aby utworzyć połączenie między portem lokalnym a portem zdalnym na serwerze aplikacji. Możesz do tego użyć narzędzi klienta ssh. Niech aplikacja kliencka połączy się z zamapowanym portem lokalnym. Następnie możesz przerwać tunel gniazdowy, aby symulować limit czasu połączenia.

Jeśli chcesz użyć aktywnego połączenia, możesz także użyć http://httpbin.org/delay/# , gdzie # to czas, przez który serwer musi czekać przed wysłaniem odpowiedzi. Tak długo, jak twój limit czasu jest krótszy niż opóźnienie ... powinien symulować efekt. Pomyślnie użyłem go z pakietem zapytań python.

Możesz zmodyfikować swoje żądanie, jeśli wysyłasz coś poufnego - nie masz pojęcia, co dzieje się z przesyłanymi do nich danymi.

Dostępne są usługi, które pozwalają sztucznie tworzyć limity czasu pochodzenia, wywołując interfejs API, w którym określasz, ile czasu zajmie serwerowi odpowiedź. Limit czasu serwera w macgyver jest przykładem takiej usługi.

Na przykład, jeśli chcesz przetestować żądanie, które zajmuje 15 sekund, wystarczy wysłać zapytanie do API Macgyver.

Ładowność JSON:

{
    "timeout_length": 15000
}

Odpowiedź API (po 15 sekundach):

{
    "response": "ok"
}

Program Timeout serwera na Macgyver
https://askmacgyver.com/explore/program/server-timeout/3U4s6g6u

Możesz zainstalować sterownik Microsoft Loopback, który utworzy dla ciebie osobny interfejs. Następnie możesz połączyć się z nią do swojego serwisu (własnego hosta). Następnie w Połączenia sieciowe możesz wyłączyć / włączyć taki interfejs ...

Mimo że nie jest do końca jasne, które OP chce przetestować: istnieje różnica między próbą połączenia z nieistniejącym hostem / portem a przekroczeniem limitu czasu już ustanowionego połączenia. Chciałbym pójść z Robem i poczekać, aż połączenie się sprawdzi, a następnie wyciągnąć kabel. Lub - dla wygody - mieć maszynę wirtualną działającą jako serwer testowy (z mostkowaną siecią) i po prostu dezaktywować interfejs sieci wirtualnej po ustanowieniu połączenia.

Techniką, której często używam do symulowania przypadkowego przekroczenia limitu czasu połączenia, jest użycie przekierowania lokalnego portu ssh.

ssh -L 12345:realserver.com:80 localhost

Spowoduje to przekazanie ruchu na localhost: 12345 do realserver.com:80 Możesz zapętlić to również na swoim komputerze lokalnym, jeśli chcesz:

ssh -L 12345:localhost:8080 localhost

Możesz więc skierować aplikację na lokalny host i niestandardowy port, a ruch zostanie skierowany do hosta docelowego: portu. Następnie możesz wyjść z tej powłoki (po wyjściu może być też konieczne naciśnięcie klawiszy Ctrl + c), a to zabije przekazywanie, które spowoduje utratę połączenia z aplikacją.

Podłącz kabel sieciowy do przełącznika, który nie ma innych połączeń / kabli. To powinno działać imho.

Jest kilka taktyk, których użyłem w przeszłości do symulacji problemów z siecią;

1. Wyciągnij kabel sieciowy
2. Wyłącz przełącznik (najlepiej za pomocą przełącznika, do którego komputer jest podłączony, nadal jest zasilany, aby urządzenie utrzymywało „połączenie sieciowe”) między komputerem a maszyną „docelową”
3. Uruchom oprogramowanie zapory na komputerze docelowym, które po cichu upuszcza odebrane dane

Jeden z tych pomysłów może dać ci sztuczny sposób na wygenerowanie potrzebnego scenariusza

W zależności od zainstalowanego / dostępnego oprogramowania zapory, powinieneś być w stanie zablokować port wychodzący, aw zależności od konfiguracji zapory powinien po prostu upuścić pakiet żądania połączenia. Brak żądania połączenia, brak połączenia, upływa limit czasu. Prawdopodobnie działałoby to lepiej, gdyby zostało zaimplementowane na poziomie routera (mają tendencję do upuszczania pakietów zamiast wysyłania resetów lub cokolwiek w tym przypadku jest odpowiednikiem), ale na pewno znajdzie się pakiet oprogramowania, który by to zrobił.

Najłatwiej byłoby porzucić połączenie za pomocą CurrPorts .

Aby jednak przetestować kod obsługi wyjątków, należy rozważyć wyodrębnienie kodu połączenia sieciowego i napisanie kodu pośredniczącego, próbnego lub dekoratora, który generuje wyjątki na żądanie. Będziesz wtedy mógł przetestować logikę obsługi błędów aplikacji bez faktycznego korzystania z sieci.

Miałem problemy w taki sam sposób jak ty. Aby przetestować zachowanie oprogramowania, po prostu odłączyłem kabel sieciowy w odpowiednim czasie. Musiałem ustalić punkt przerwania tuż przed tym, jak chciałem odłączyć kabel.

Gdybym to zrobił ponownie, umieściłbym przełącznik (normalnie zamknięty przycisk chwilowo jeden) w kablu sieciowym.

Jeśli fizyczne rozłączenie powoduje inne zachowanie, możesz podłączyć komputer do taniego koncentratora i umieścić wspomniany wyżej przełącznik między koncentratorem a siecią główną.

- EDYCJA - W wielu przypadkach połączenie sieciowe będzie działać, dopóki nie dojdziesz do określonego punktu w programie, NASTĘPNIE będziesz chciał się rozłączyć, korzystając z jednej z wielu zaproponowanych sugestii.

Dla mnie najprostszym sposobem było dodanie trasy statycznej na routerze biurowym w oparciu o sieć docelową. Po prostu przekieruj ruch do jakiegoś niereagującego hosta (np. Twojego komputera), a otrzymasz limit czasu żądania.

Najlepszą rzeczą dla mnie było to, że statyczną trasą można zarządzać przez interfejs sieciowy i łatwo włączać / wyłączać.

Możesz spróbować połączyć się z jedną ze znanych witryn sieci Web na porcie, który może nie być dostępny z zewnątrz - na przykład 200. Większość zapór ogniowych działa w trybie DROP i zasymuluje dla ciebie limit czasu.