Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

using winsock control

Status
Not open for further replies.

JimmyK

Programmer
Sep 8, 2000
142
VN
In vf 6.0, i use microsoft winsock control to connect to some other servers, it's OK.

When i use winsock ocx control to play the server role. Methods: listen, accept, senddata, getdata function properly but when client programs quit - call CientSock.close to close sock and then exit - my VF winsock server halt - it does not respond and i have to press CTRL+ALT+DEL to stop it.

I try the same code in Visual Basic. it's OK: when clients quit, ServerSock.State channge immediately and the program still work.

How can i work around this problem?

Thanks in advance

[sig][/sig]
 
Because you mentioned the Listen method, you must be using the TCP protocol and not UDP. I've heard people complain that they couldnt get the Winsock control to function properly in VFP when using TCP because it requires a permanent connection. They ultimately used UDP because it's a connectionless protocol. But I'm NOT saying TCP won't work under VFP.

So, One possible solution is to use UDP instead of TCP.

Another SWAG, prior to the WinSock.Close call in the client app, have the client app send a message to the server app and allow the server to close the connection.

Either way, I'd like to hear how you ultimately resolve this. [sig]<p>Jon Hawkins<br><a href=mailto: jonscott8@yahoo.com> jonscott8@yahoo.com</a><br><a href= > </a><br>Carpe Diem! - Seize the Day![/sig]
 
Thanks Jon
The way you recommended is right but the problem is when client program halt, or user poweroff without quiting the client program.

I am going to use C++ to write the server program.

Note: i used TCP protocol and it function properly in client side. I am still waiting for any other solutions

Jimmy [sig][/sig]
 
Hi jimmy

Actually, we have the same problem with the winsock client application. We have spotted the problem to the fact that in case that the control has a method and event or a method and a property with the same name the VFP6 get confused and instead of calling the method calls the event. In VB6 there is no problem. Have you any idea how I can discriminate and call specifically the method and not the event?

The method connect() and close() have the same name with the events connect() and close(). Actually you can see the VFP6 confussion from the property window where only the events are shown.

If you have resolve the problem I would appreciate if you reply to me in my e-mail

vglaros@olympic-airways.gr

Thank you in advance
 
Hi Vglaros
At server side, i gave up.
And here is the tips at client side: Instead of calling winsock1.connect(), i called winsock1.object.connect().

When calling methods, please call winsock1.object.method()

Hope it helps

Jimmy K

 
Concerning your problem, I think that the connection doesn’t close automatically when the Winsock object is destroyed. That must be true for Visual Basic.

What you have to do is to add “this.object.close()” in the close event as well as in the Destroy event of the Winsock objects (server and client).

From server side, you must put this on the listening socket (to be correct), and specially to the answering socket, the one that performs the Accept method.

If you dynamically create an answering socket, in order to accept more calls then you have to subclass from Winsock, put in this class the above statement and use this class to create your dynamic answering socket.

I noticed the same problem, because I forgot to put the above statement to the write places (all of them). After that the problem disappeared.

I hope the above will help you. If you notice any problem or have any other question please let me know. I am interested on the subject also.


 
Hi Vglaros and All,

Your tips really helps but i am facing the problem when subclassing Winsock Control.

I subclass WS control like this:



******************************************
DEFINE CLASS oleMsgSock as OLEControl
protected sending
OleClass =&quot;mswinsock.winsock&quot;
*************

Proc init
*this.localport = 80
endproc

Proc Close &&&&&&&&&&&&&&&&
?This.remotehostip + &quot; shutdown&quot;
=This.object.close()
=This.parent.CloseSock(This.name) && lets parent form to remove this object

endproc && Close

Proc DataArrival &&&&&&&&&&&&&&&&&&&7
LPARAMETERS bytestotal
priv tam , f, buffer
tam=&quot;&quot;
=This.object.Getdata(@tam)

? &quot;Recievd from &quot; + this.object.remotehostip

f = fopen(&quot;c:\tmp\default.txt&quot;)


do while not feof(f)
buffer= fread(f,512)
=This.Senddata(buffer)
doevent
enddo

=fclose(f)

=This.object.close()
=This.parent.CloseSock(This.name)

Endproc && DataArrival


ENDDEFINE



Ofcourse i have another WS control to listen on port 80.

When clients connect, i create an &quot;oleMsgSock&quot; to reply( reading default.txt and sending to client). When default.txt is large, it really blocks - other connections will fail

Does anyboby have the solution to work around this?

Thanks

Jimmy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top