SOAP Web Service

 ( J0se | 2019. június 20., csütörtök - 16:11 )

Sziasztok!

Adott egy ASP.NET web service amely felé egy kliens alkalmazás 4 db request-et indít. Az első 3 db darab request hiba nélkül elküldésre kerül
és a válasz is megérkezik. A 4. request is elküldésre kerül (elvileg) a másik oldal szakemberei látják a beérkezett request-et, sőt azt is látják, hogy a response is elküldésre került a kliens-nek, de a kliens mégis timeout-ra fut, és nincs válasz.

SAOP UI-val is teszteltem a dolgot és ugyanez a helyzet.

Még szebbé teszi a dolgot, hogy ez a probléma csak egyetlen gépen jelentkezik, ha más gépen próbálkozunk a dologgal, ott mind a 4 db request elküldésre kerül és a válaszok is rendben megérkeznek.

Találkozott valaki esetleg már ilyen problémával, vagy esetleg tudna adni támpontokat, hogy milyen irányban kellene elindulnom?

Operációs rendszer: Windows 10 Pro (1809)

A válaszokat előre is köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

nekem amikor legutóbb volt hasonló probléma, akkor egy "nem létező" proxy blokkolt random kéréseket a kliens és szerver között

Nincs beállítva a proxy használat.

szerintem transzparens proxyra gondolom ami bizonyos esetekben megse volt az :-). pl haproxy

Még az alábbiakat érdemes lenne megnézni:
- Válaszok mérete uyganakkora? A 4. nem sokkal nagyobb?
- Ha nem párhuzamosan indítod, akkor is fennáll a hiba azon a gépen?
- Kikapcsolt tűzfal esetén?
- Másik IP-t adni a gépnek, másik hálókártyát beletenni, más hálózaton fellógatni a netre, hogy hívja a SOAP-ot.

Ezekkel lokalizálható a hiba "helye" egy kicsit.

- De a 4. response-ban kapott XML sokkal nagyobb mint a többi
- Nem párhuzamosan indítottam őket
- Kikapcsolt tűzfal sem segített sajnos
- A másik IP-s megoldást még nem próbáltam, most az fog következni

Köszönöm az ötletet!

Nekünk volt valami IIS cucc a szerver oldalon ami nem küldte ki a nagy válaszokat. Az asp kód előállította, de a szerver elnyelte.
Itt valami kliens cucc lehet ha csak az egyik gép nem kapja meg. De valami hasonló réteg okozhatja.

esetleg vmi balfasz altal tiltott ICMP nem mukodo PMTUval?
Mekkorak a valaszaid? MTU a sender oldalon?

Az első 3 response mérete amelyek megérkeznek kb: 300 - 400 Byte.
A negyedik response jelenlegi mérete: 83 643 Byte.

MTU: 1 500

Nagyobbra gondoltam, 10+MB. Ez így nem sok. Lehet hogy a számítógép ujratelepites fogja megoldani és soha nem derül ki :)

Hát sajnos az már megtörtént, egyszerűen nem boldogultunk a problémával, már nagyon régóta nem találjuk a megoldást, és úgy döntöttünk hogy inkább újrahúzzuk az egészet, de sajnos nem oldotta meg.

Nincs valami tapír vírusvédelmi megoldás installálva?

ESET NOD32 fut a gépen, de ha kikapcsolom, akkor sem működik a dolog.

Van a mesében SSL és IIS?
https://hup.hu/node/154999

Wireshark mit mond? Bejon az uzenet? Kimegy a valasz?

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

retegrol retegre :-).
kliens server komponensek sajat logjai, ha az nincs akkor pld tcpdump\wireshark.

Kliens oldal: Wireshark és SOAPUI log szerint is kimegy a request, de a response-t egyik sem látja.

Szerver oldal: A Web Service log szerint beérkezik a request, feldolgozásra kerül, elkészíti a választ, és ki is küldi azt. (És biztos, hogy így is van mert másik gépről indítva a request-et, az adott kliens adataival rendben megérkezik a válasz)

Mivel a gép hálózati beállításai teljesen megegyeznek egy másik olyan gépével ahová megérkezik a válasz, más csak a router-re tudok gyanakodni...

a kliens hálókártyájába érkező kábelt bontsd meg egy !!HUB!! -bal és nézd egy másik gépen, hogy ott látod-e az adatot.
Menj fel így a fizikai rétegben addig ameddig csak tudsz, és ki fog derülni, hogy hol akad meg a paket.

A végén kiderül hogy egy bit el van b*szodva a halokartyaban.

Hát szerintem fogom a hálózati kártyát, kidobom és egy teszt erejéig teszek bele egy másikat.

érdekes. bármi más ugyanazon a porton közlekedő szolgáltatás megy?

Igen, meg a többi request is ezt a portot használja, és nem hasalnak el.

no kiderült valami? :)

Wireshark. Mi folyik odalent
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?

Nos, kukáztuk a hálózati kártyát, ami a gépben volt, és kapott egy teljesen újat. Így most gyönyörűen működik a WebService kommunikáció.

érdekes ;)

Igaz volt a mondás, hogy valamelyik komponens volt a ludas. Egy idő után mindenre (is) kell gondolni.

Hát lehet, hogy túl naiv vagyok, de végig abban a hitben voltam, hogy ha egy fizikai komponens (jelen esetben a hálózati kártya) hibás, akkor az a hiba más téren is jelentkezik, mondjuk böngészés közben, vagy más szervereken lévő Webservice-ek hívása során.

nem feltetetlen, futottam bele olyan fw issueba, hogy adott MSNrol jovo voip call triggerelt phy shutdownt, de annyira h poweroff kellett, a link led meg vigan viritott...

biztos a fizikai hálókártya volt rossz?

nem lehet hogy a hálókártya device reinstall helyrebillentett vmi hálózati beállítást ami okozta?

A fizikai eszköz volt rossz, mivel ha visszateszem a régi hálózati kártyát, akkor ugyanúgy nem működik a dolog.