[ASP.NET 1.1] Webservice response handling issue

[DrDelete]

Ik heb een webmethod. Stel dat een request binnenkomt en de uitvoering van de webmethod laat even op zich wachten. Tijdens deze verwerking aan de server-kant gaat de client onderuit of wordt gestopt. De webmethod retourneert gewoon zijn antwoord, zonder dat er een exception optreedt aan server-zijde.

Mijn vraag: is er een mogelijkheid om te controleren of de client nog aanwezig is bij het teruggeven van het antwoord?

[TeeDee]

Mijn vraag is: waarom wil je dat? Is het zo dat de server afhankelijk is van de client? Zo ja, dan klopt er iets niet met de flow van je applicatie.

Ik kan me in ieder geval niks voor de geest halen. Her en der met wat workarounds, maar de tijd die je nodig hebt om met workarounds aan de slag te gaan vallen denk ik in het niet bij het probleem zelf.

[ Voor 41% gewijzigd door TeeDee op 17-03-2008 09:57 ]

[DrDelete]

TeeDee schreef op maandag 17 maart 2008 @ 09:56:
Mijn vraag is: waarom wil je dat? Is het zo dat de server afhankelijk is van de client? Zo ja, dan klopt er iets niet met de flow van je applicatie.

Ik kan me in ieder geval niks voor de geest halen. Her en der met wat workarounds, maar de tijd die je nodig hebt om met workarounds aan de slag te gaan vallen denk ik in het niet bij het probleem zelf.

de klant wil dat

[TeeDee]

Als workaround: hou een lijst bij met connected clients (ip, name, etc) en poll deze lijst voor- en evt. na dat je het antwoord terug geeft. Is de client foetsie > Exception.

[ Voor 10% gewijzigd door TeeDee op 17-03-2008 11:06 ]

[pedorus]

DrDelete schreef op maandag 17 maart 2008 @ 10:58:
de klant wil dat

De vraag is dan natuurlijk waarom de klant dat wil.. En vooral of hij dat echt wil...

[DrDelete]

pedorus schreef op maandag 17 maart 2008 @ 11:14:
[...]

De vraag is dan natuurlijk waarom de klant dat wil.. En vooral of hij dat echt wil...

De klant wil reliable messaging. Er moet een soort bewijs zijn aan de webservice-kant dat het request is ontvangen, op het moment van antwoord geven moet getoetst worden of de client er nog is, is deze er niet dan moet dit gelogd worden.

[TeeDee]

Stuur een Response uit. Verwerk in die Response iets van een controlelink, image wat dan ook. Volgt er na de Response direct weer een request (met unieke code oid), dan kan je er nagenoeg vanuit gaan dat het antwoord binnen is.

Nu weet ik natuurlijk niet of er nog wat aan de webservice qua Response aan te passen is dus is deze workaround misschien niet mogelijk.


Jij wil reliable messaging? Jij krijgt reliable messaging

[ Voor 22% gewijzigd door TeeDee op 17-03-2008 13:38 ]

[pedorus]

Dan lijkt me dat de client na ontvangst nog een berichtje stuurt als het afgehandeld is. Als de server dit gaat checken, dan kan het alsnog fout. Bijvoorbeeld als de client tussen het checken en het versturen dood gaat. Of als het bericht wel ontvangen is, maar de client het niet meer goed weet af te handelen.

[Voutloos]

DrDelete schreef op maandag 17 maart 2008 @ 13:26:
[...]
De klant wil reliable messaging.

Misschien moet de klant dan maar zorgen voor een stabiele client, responses indien mogelijk cachen en/of requests queuen, niet zomaar de applicatie laten afsluiten als er een request pas net bezig is, etc. etc.

Anyway, definieer klant. Is klant een bedrijf waarvoor je zelf zowel de server als client app maakt, is het enkel de client app, of is het enkel 1 vd mogelijke clients apps?

En waarom moet falen van een client op de server gelogd worden? Als voornaamste reden kan ik enkel op het niet door client willen betalen van niet verwerkte responses, maar als de response gewoon verstuurd is, is dat _altijd_ de schuld van de client zelf.