[.NET] Socket connect timeout

[CodeIT]

Ik heb het probleem met .NET (vooral vb in mijn geval), dat als ik een socket wil verbinden met connect en de betreffende pc met het ip niet aanstaat/reageert, dat er dan een timeout optreed van bijna 2 minuten.
De 2 minuten zijn wel erg veel, maar dat kan komen doordat ik over wireless zit en dat de timeout wordt vastgelegd op je netwerkkaart.
Ik heb al geprobeerd om een asynchrone connect te doen, door BeginConnect aan te roepen en dan met een WaitHandle van bv. 20 seconden het connecten te stoppen. Alleen endconnect is weer een synchrone functieaanroep, dus dit veroorzaakt ook weer dezelfde timeout.
Ik heb ook al op een andere pc, zonder wireless getest en daar was de timeout minder, maar nog steeds best lang (45 seconden).
Ook heb ik geprobeerd om de receivetimeout en sendtimeout laag te zetten, maar met connecten maakte dit niets uit.
Dus, mijn vraag: Heeft iemand een oplossing/workaround hiervoor?

[Infinitive]

Er zijn wel oplossingen voor waarbij je de timeout beter in de hand hebt. Een jaar geleden heb ik daar nog mee gewerkt, maar helaas kan ik je op het moment geen concreet antwoord geven. Als niemand binnen afzienbare tijd reageerd zal ik wel even op zoek gaan naar het antwoord (dat is: even nieuwe msdn installeren want een oude versie heb ik er een paar dagen geleden juist afgegooid...).

Eén ding waar je op moet letten: bijna bij al die IAsync dingen heb je een end methode die altijd het uiteindelijke resultaat oplevert. Wanneer je dus een bepaalde operatie wilt afbreken moet je die methode dus niet gebruiken want dan gaat 'ie dus net zolang wachten totdat er een resultaat beschikbaar komt.

Misschien is het een idee om eerst je socket af te sluiten en dan EndConnect aan te roepen? (het zal dan wel falen, maar dat is natuurlijk te verwachten). Maar dit is maar een gokje uit losse pols hoor, ik kan me namelijk goed voorstellen dat je op het moment dat je aan het connecten bent nog helemaal geen socket voorhanden hebt - of in ieder geval niet in een geopende toestand.

[CodeIT]

Infinitive schreef op 30 maart 2004 @ 19:44:
Misschien is het een idee om eerst je socket af te sluiten en dan EndConnect aan te roepen? (het zal dan wel falen, maar dat is natuurlijk te verwachten). Maar dit is maar een gokje uit losse pols hoor, ik kan me namelijk goed voorstellen dat je op het moment dat je aan het connecten bent nog helemaal geen socket voorhanden hebt - of in ieder geval niet in een geopende toestand.

Ja, dat was mijn idee eigenlijk ook, maar dit mislukt, zoiets van: "Ben nog met asynchrone operatie bezig, waag het niet om te closen". De socket blijft dus gewoon bestaan, en om dan een nieuwe socket aan te maken terwijl de andere bezig is geen optie. Vooral omdat dit alles in een threadpool gebeurd, waar zeer veel sockets worden geopend.
Ik kan wel leven met een timeout van 20 seconden ofzo, alles gebeurd toch op de achtergrond, maar 2 minuten .

[Infinitive]

Ik kom erachter dat ik helaas geen oplossing voor je heb. Ik kon blijkbaar toen ook niet een manier vinden om zo'n asynchrone operatie af te breken. Mijn manier was door het ding in de achtergrond maar gewoon lekker door te laten connecten en bij de socket een boolean bijhouden of dat ding afgebroken was ja of nee. Dus als uiteindelijk dan toch nog een connectie opgezet was, tja, dan had 'ie dus gewoon pech gehad. Dat die timeouts zo lang is had ik dus ook.

Je gaf zelf al aan dat dit geen oplossing voor je is? Is het nog open staan hebben van een aantal connects zo'n probleem? Ik denk nml. dat zo'n asynchrone operatie geen actief jobje in je threadpool in beslag neemt (alleen op het moment dat die callback uitgevoert wordt), dus wat dat betreft zie ik geen problemen.

Wat als je een Dispose() op een socket doet? Waarschijnlijk krijg je dan wel een dikke exception voor je kiezen. Hoewel je uit moet kijken met dit soort dingen, want een deadlock zit in een klein hoekje...

[farlane]

Voor het connecten moet je denk zelf een constructie bouwen met een async connect en select oid.

Om de tijd dat een 'geclosede' socket nog leeft te beinvloeden kijk eens naar setsockopt met SO_LINGER en de opties die daar bij horen.

[CodeIT]

farlane schreef op 30 maart 2004 @ 23:25:
Voor het connecten moet je denk zelf een constructie bouwen met een async connect en select oid.

Om de tijd dat een 'geclosede' socket nog leeft te beinvloeden kijk eens naar setsockopt met SO_LINGER en de opties die daar bij horen.

Heb een gezocht op SO_LINGER, maar dit schijnt gaat alleen over gequeuede data te gaan bij het aanroepen van een close:

SO_LINGER controls the action taken when unsent messages are queued on socket and a close(2) is performed. If the socket promises reliable delivery of data and SO_LINGER is set, the system will block the process on the close(2) attempt until it is able to transmit the data or until it decides it is unable to deliver the information (a timeout period, termed the linger interval, is specified in seconds in the setsockopt call when SO_LINGER is requested). If SO_LINGER is disabled and a close(2) is issued, the system will process the close in a manner that allows the process to continue as quickly as possible.

Ik zal morgen even kijken of dit echt zo is. Volgens mij zit er niet veel anders op dan, of de timeout te accepteren, of zoals gezegd een eigen constructie te bouwen. Maar bij het openen van 1000+ sockets moet ik wel uitkijken voor deadlocks en overmatig geheugenverbruik.