Hi all,
I've been using ICS for a long time, in different environments and on
different machines without problems.
Now I've stumbled upon a problem of which at the moment I don't know how
to find a solution for. It's regarding a snippet which sens data using UDP.
The relevant code boils down t
>>> Does anyone have ideas why TIcsWndControl.ProcessMessages could
>>> hang sometimes when socket is used in separate thread?
>
>>Have you followed the rules: create TWSocket within the thread's execute
>>method OR call ThreadAttach ?
>
> Yes socket is created within threads execute method, and it
Merijn Bosma wrote:
> Hi all,
>
> I've been using ICS for a long time, in different environments and on
> different machines without problems.
> Now I've stumbled upon a problem of which at the moment I don't know
> how to find a solution for. It's regarding a snippet which sens data
> using UDP.
I suggest you look at "security software" which may be installed on those
PC. Some of those software (anti-malware, firewall, proxy,...) are
malfunctionning in their interception of socket communication. So first do a
test with every security software disabled.
It may also be a virus or trojan
Does anyone have ideas why TIcsWndControl.ProcessMessages could
hang sometimes when socket is used in separate thread?
Actually ProcessMessages probably doesn't hang. ProcessMessages it the
place
from where all events are called. It is likely an event handler which is
blocking. You should try
New message while I was typing the reply to the previous one :)
Fraincois, I've been able to reproduce this on a fresh installed machine
(no internet connection). Windows firewall is disabled, no extra
software installed. I think that will rule out a external software issue?
Besides, we see ex
On 7/12/2011 19:26, Arno Garrels wrote:
That sounds very similar to an issue Francois reported several months
back and which turned out to be a winsock bug IMO.
In Vista+ winsock repeated the ARP request within a few seconds 2 times
to get the MAC address that accepts packets for the destination
Merijn Bosma wrote:
> Was Francois able to find a way to make sure this is the case, or a
> work around?
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the
IP Helper API.
--
Arno Garrels
--
To unsubscribe or change
Was Francois able to find a way to make sure this is the case, or a
work around?
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the
IP Helper API.
Yes, that what I did.
--
francois.pie...@overbyte.be
The author of
How can I confirm that this is what's happening with me?
Merijn
On 7/12/2011 21:49, Francois PIETTE wrote:
Was Francois able to find a way to make sure this is the case, or a
work around?
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exis
> I call it like this, the only event that is called is SslShutDownComplete
> which
> sets FSSLShutdownComplete property, I don't have any other event
> processing here
>
> FSocket.Shutdown(SD_BOTH);
>
> EndTime := GetTickCount + FTimeout;
> while {$IFDEF USE_SSL} not FSSLShutdownComplete {$EL
Merijn Bosma wrote:
> How can I confirm that this is what's happening with me?
As far as I recall it was required to have a TTimer running
in order to repeat this issue, very very strange.
Make a simple test application and verify that line
"iStatus := WSocket_Synchronized_closesocket(FHSocket);"
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the IP Helper
API.
Yes, that what I did.
How can I confirm that this is what's happening with me?
In my case, the blocking was occuring in the main thread. TO see i
13 matches
Mail list logo
