On Mon, 14 Sep 2009, Pritpal Bedi wrote: Hi,
> I did as follows: > 1. Opened a port on my router, 63000, to be accessible from outside. > 2. Obtained temporary IP for my computer from no-ip .com, say, 64.123.212.67 > 3. Verified that the port 63000 is visible on that IP with some net tool. > 4. Started NetIOSrv.exe 63000 0.0.0.0 c:\someFolderAsRootFolder > 5. Executed the application with 64.123.212.67 63000 > Application just hanged for indefinitely and did not showup next screen. > Normally if port is not accessible or NerIOSrv.exe is not running, > application returns immediately with an error. > What could be the reasons for this behavior? I guess that you are talking about client application not server and it stops inside connect(). Usually low level TCP/IP code in the OS should interrupt this operation after some timeout if it cannot be realized. Sometimes this timeout is really huge. It depends on many things, i.e. average time of packet confirmation which in TCP IP is dynamically updated following the transport layer quality. Anyhow it's out of Harbour or any other application controll. If connection freeze the process forever then I can only guess it's side effect of used firewall or some other similar protection software. Otherwise it's serious bug in TCP/IP implementation which should be reported to MS but I rather do not believe that Windows has such serious problem with basic functionality. If you can exclude some other trivial problem like mistakes in routing tables or sth like that then for me it has to be problem with firewall which blocks connection only partially and may send some sync packages waiting for user interaction (i.e. to confirm if connection is legal) what effectively blocks timeout on client side. If you want to you can pass as 3-parameter of netio_connect() timeout in milliseconds. Default is -1 what means not user space timeout and operation should be interrupted by OS inside connect() function. If you use 10000 then after 10 sec. netio_connect() will return .F. signaling the problem. Of course it's only workaround with protection against freezing the application not real solution but because the problem is outside Harbour I cannot suggest you anything more as programmer solution (I do not want to introduce some low level TCP/IP hacks because in most of cases they increase the problem instead of help ;-)) Look at your firewall configuration. It's possible that the problem is trivial, i.e. firewall needs valid DNS entry for client and/or server station and it's enough to disable such verification. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
