Kontekst: Przekazuję aplikację perl linux do C#, serwer nasłuchuje na porcie udp i utrzymuje wiele równoległych dialogów ze zdalnymi klientami za pośrednictwem pojedynczego gniazda udp. Podczas testowania wysyłam duże ilości pakietów do serwera udp, losowo restartując klientów, aby obserwować serwer rejestrujący nowe połączenia. Problem polega na tym, że gdy zabijam klienta udp, nadal mogą istnieć dane na serwerze przeznaczonym dla tego klienta. Gdy serwer spróbuje wysłać te dane, otrzyma komunikat "brak usługi", i w konsekwencji nastąpi wyjątek na gnieździe.Jak odzyskać wdzięk z wyjątku C# udp socket
Nie mogę ponownie użyć tego gniazda, gdy próbuję powiązać obsługę asynchronizmu C# z gniazdem, skarży się na wyjątek, więc muszę zamknąć i ponownie otworzyć gniazdo udp na porcie serwera. Czy to jedyny sposób obejścia tego problemu ?, z pewnością istnieje sposób "naprawienia" gniazda udp, ponieważ technicznie, gniazda UDP nie powinny być świadome stanu zdalnego gniazda?
Każda pomoc lub wskazówki byłyby mile widziane. Dzięki.
dobrze, technicznie, stos sieciowy jest świadomy zamkniętego portu udp, jeśli zdalny koniec odsyła sygnał "docelowy nieosiągalny" icmp, co robią niektóre implementacje. Może spróbuję tymczasowo zablokować program icmp i zobaczę, czy dostaję te same wyjątki ... –
@gearoid Nawet wtedy wysyłanie innego pakietu powinno działać, ponieważ gniazdo nie ma możliwości sprawdzenia, czy port jest z powrotem podłączony, czy nie – Toad
istnieje rozróżnienie między * podłączonymi * i * niepołączonymi * gniazdami UDP. W przypadku pierwszego z nich jądro wie, do której aplikacji należy kierować ten błąd ICMP; w drugim przypadku nie, więc błąd nie zostanie dostarczony. Wszystko sprowadza się do przypisania portu gniazda. Wtedy nie mam pojęcia, jak to działa z .NET. –