[VB.NET] Socket.Receive timeout - Softwareontwikkeling

donderdag 24 mei 2007 11:31

Acties:

Topicstarter

Hoi,

even een kort vraagje. Ik open een socket naar een server met een receivetimeout van 5 sec. Wanneer de socket is verbonden en ik receive aanroep op de socket zal hij na 5 sec een SocketException gooien als er geen data is ontvangen in de tussentijd. Vervolgens roep ik de receive weer overnieuw aan in een loopje.

Stel nu dat tijdens de blocking receive van 5 sec de verbinding is weggevallen / verbroken door de server en de client heeft dit niet meegekregen. Wordt dan bij de volgende socket.receive call een exceptie gegooid dat de verbinding eruit ligt? Of wordt dit niet meer gechecked in de receive?

Ik heb gezocht in de MSDN documentatie maar kan hier geen duidelijk antwoord vinden. Testen is ook lastig, krijg het niet gereproduceerd dat de client een disconnect niet meekrijgt (in de praktijk gebeurt dit wel).

Het is trouwens voor .net 2.0 compact framework

Iemand een idee?

donderdag 24 mei 2007 14:18

Acties:

farlane

Test je verbinding via een switch of hub en trek van de verzender kant de kabel eruit. zit.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

vrijdag 25 mei 2007 09:44

Acties:

Cavalera125

Topicstarter

Bedankt voor de tip. Heb ik getest, het blijkt dat ik niet op de hoogte gebracht wordt van een disconnect wanneer ik de verzender kant eruit trek. Wanneer ik de receive vervolgens opnieuw aanroep krijg ik geen disconnect mee, alleen de timeoutexception op de receive komt terug.

Wanneer ik na deze timeout een send over de socket stuur krijg ik na een x aantal keer (+- 20 sends / 20 - 40 seconde) wel een disconnect. Is er wellicht een manier om deze disconnect eerder op te merken?

vrijdag 25 mei 2007 10:31

Acties:

Woy

Moderator Devschuur®

Ik denk dat het probleem in de TCP stack van de device ligt. In princiepe zou je Receive en Send gewoon meteen moeten stoppen op het moment dat de verbinding verbroken wordt.

Je device heeft waarschijnlijk een hele hoge time-out waarde staan bij het niet ontvangen van een response. Als de verbinding correct gesloten wordt dan gaat het waarschijnlijk wel goed omdat er dan wel een close bericht verstuurd wordt waardoor je device meteen de disconnect opmerkt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

vrijdag 25 mei 2007 10:33

Acties:

Cavalera125

Topicstarter

Zit die timeout in het OS, of is die vanuit de code aan te passen? Wanneer ik de stekker aan de ontvang kant (de client) eruit haal dan komt er wel meteen een disconnect binnen.

vrijdag 25 mei 2007 10:37

Acties:

bigbeng

@rwb: Volgens mij is dat niet helemaal waar. TCP/IP of TCP alleen zijn in principe stateless ten opzichte van de fysieke verbinding. Dat er een timeout optreedt is dus logisch.

Het hele idee achter TCP/IP is juist dat er een verbinding in het netwerk kan uitvallen zonder dat dat gevolgen heeft, omdat de routing dan automatisch via een andere (in jouw geval niet aanwezige) verbinding gaat lopen.

[ Voor 39% gewijzigd door bigbeng op 25-05-2007 10:41 ]

vrijdag 25 mei 2007 10:50

Acties:

farlane

rwb schreef op vrijdag 25 mei 2007 @ 10:31:
Ik denk dat het probleem in de TCP stack van de device ligt. In princiepe zou je Receive en Send gewoon meteen moeten stoppen op het moment dat de verbinding verbroken wordt.

Je krijgt een disconnect alleen als aan bv de verzender kan de socket clean wordt geclosed. Andere uncleane disconnects zie je alleen als je een send of receive (opnieuw)aanroept.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

vrijdag 25 mei 2007 10:51

Acties:

farlane

Cavalera125 schreef op vrijdag 25 mei 2007 @ 10:33:
Zit die timeout in het OS, of is die vanuit de code aan te passen? Wanneer ik de stekker aan de ontvang kant (de client) eruit haal dan komt er wel meteen een disconnect binnen.

Dat komt omdat je os dan een medium disconnect ziet. Het gaat hier om bv een fout aan de verzender kant die je moet detecteren aan de receiver kant.

[ Voor 5% gewijzigd door farlane op 25-05-2007 10:51 ]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

vrijdag 25 mei 2007 11:38

Acties:

Cavalera125

Topicstarter

farlane schreef op vrijdag 25 mei 2007 @ 10:50:
Andere uncleane disconnects zie je alleen als je een send of receive (opnieuw)aanroept.

Klopt, alleen duurt het dan nog een hele tijd (20 - 40 seconde) voordat er daadwerkelijk een disconnect gezien wordt. Is dit aan te passen of op een andere manier op te lossen?

vrijdag 25 mei 2007 13:01

Acties:

Woy

Moderator Devschuur®

bigbeng schreef op vrijdag 25 mei 2007 @ 10:37:
@rwb: Volgens mij is dat niet helemaal waar. TCP/IP of TCP alleen zijn in principe stateless ten opzichte van de fysieke verbinding. Dat er een timeout optreedt is dus logisch.

Het hele idee achter TCP/IP is juist dat er een verbinding in het netwerk kan uitvallen zonder dat dat gevolgen heeft, omdat de routing dan automatisch via een andere (in jouw geval niet aanwezige) verbinding gaat lopen.

Ja dat bedoel ik dus ook. Daarom zeg ik dat die timeout die bepaald of de connectie "Verbroken" in de TCP/IP stack zit.

farlane schreef op vrijdag 25 mei 2007 @ 10:50:
[...]

Je krijgt een disconnect alleen als aan bv de verzender kan de socket clean wordt geclosed. Andere uncleane disconnects zie je alleen als je een send of receive (opnieuw)aanroept.

Ja dat bedoelde ik dus met

rwb schreef op vrijdag 25 mei 2007 @ 10:31:
Als de verbinding correct gesloten wordt dan gaat het waarschijnlijk wel goed omdat er dan wel een close bericht verstuurd wordt waardoor je device meteen de disconnect opmerkt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

vrijdag 25 mei 2007 14:39

Acties:

Woy

Moderator Devschuur®

Mischien dat je met Socket.SetSocketOptions nog het een en ander kunt tweaken. Maar ik denk niet dat je het nooit helemaal goed krijgt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

vrijdag 25 mei 2007 16:08

Acties:

farlane

rwb schreef op vrijdag 25 mei 2007 @ 14:39:
Mischien dat je met Socket.SetSocketOptions nog het een en ander kunt tweaken. Maar ik denk niet dat je het nooit helemaal goed krijgt.

Jawel, je zult alleen zelf een timeout mechanisme bouwen met nonblocking sockets of select bv.

[ Voor 13% gewijzigd door farlane op 25-05-2007 16:08 ]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

zaterdag 26 mei 2007 10:44

Acties:

Woy

Moderator Devschuur®

farlane schreef op vrijdag 25 mei 2007 @ 16:08:
[...]

Jawel, je zult alleen zelf een timeout mechanisme bouwen met nonblocking sockets of select bv.

Ja tuurlijk kan het wel. Maar het blijft zo dat je niet direct kan detecteren of de connectie weg is. Er kan ook gewoon wat delay op treden. Zeker met mobile devices is dat best reeel.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

zaterdag 26 mei 2007 11:43

Acties:

farlane

rwb schreef op zaterdag 26 mei 2007 @ 10:44:
Ja tuurlijk kan het wel. Maar het blijft zo dat je niet direct kan detecteren of de connectie weg is. Er kan ook gewoon wat delay op treden. Zeker met mobile devices is dat best reeel.

Ja das waar, een besluit of de andere kant er niet meer is zal altijd gebaseerd zijn op een timeout constructie.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Pagina: 1

Reageer