Printable View
I don't understand why I'm getting this error... here's the deal, the following is the code:
MessThe$ = "bleh"
frmMain.Winsock1.SendData (MessThe$)
and the following is the error:
Run-time Error '40006':
Wrong protocol or connection state for the requested transaction or request
What could cause that error? I'm connected to them through winsock... I don't see why it isn't working. Any help is thanked in advance. Later,
-zer0 flaw
What is your 'localport' and what is your 'remoteport', the error will lie in these...
I set the "local port" to 1000 and the remote computer connects to that port on the local computer. So what's the error with that?
Modify the code so it locks something like this...
MessThe$ = "bleh"
If frmMain.Winsock1.State = sckConnected then
frmMain.Winsock1.SendData (MessThe)
else
Do until frmMain.Winsock1.State = sckConnected
Doevents: Doevents: Doevents: Doevents
Loop
frmMain.Winsock1.SendData (MessThe)
End if
This code checks if Winsock1 is connected and if it isn't it does a loop to wait for Winsock to become connected.
But this loop can go on and on forever so you can modify it how you like.
A good thing is to set in a counter that counts the loop and stops it at a number of loops.
I have many times got similar errors and if you look at the reciving Winsock it accepts the connection and becomes connected but the sending Winsock is still connecting.
I think that it's some kind of bug in Winsock...
If someone else thinks otherwise they are welcome to say so...
//Thomas Vanhaniemi
You are correct in that you should test Winsock1.State and not send anything until it equals sckConnected. And you should also set a timer to wait for for the connection to complete. If the connection does not complete within a reasonable time, some error recovery should take place.Quote:
Originally posted by Thomas Vanhanie
Modify the code so it locks something like this...
MessThe$ = "bleh"
If frmMain.Winsock1.State = sckConnected then
frmMain.Winsock1.SendData (MessThe)
else
Do until frmMain.Winsock1.State = sckConnected
Doevents: Doevents: Doevents: Doevents
Loop
frmMain.Winsock1.SendData (MessThe)
End if
This code checks if Winsock1 is connected and if it isn't it does a loop to wait for Winsock to become connected.
But this loop can go on and on forever so you can modify it how you like.
A good thing is to set in a counter that counts the loop and stops it at a number of loops.
I have many times got similar errors and if you look at the reciving Winsock it accepts the connection and becomes connected but the sending Winsock is still connecting.
I think that it's some kind of bug in Winsock...
If someone else thinks otherwise they are welcome to say so...
//Thomas Vanhaniemi
I can't say that I have ever seen the "receiving Winsock" (the server) go to a connected state while the "sending Winsock" (the client) is still connecting. It may be that the network is busy and the client is still waiting for the SYN ACK from the server.
One sure way to create the error that zer0_flaw is geting is to use the same LocalPort number for each connection. If you close the connection and reopen it in a very short time, the socket may still be in TIME_WAIT state. See thread http://161.58.186.97/showthread.php?s=&threadid=74990 for more on this.
I reccommend not specifying LocalPort and letting the OS pick one for you. It will be different every time you connect.
If the server doesn't use the Accept method and instead is trying to send while still listening, that will cause the error zer0_flaw is getting. After starting the server socket with the Listen method, use the Connection_Request event to Accept the request and *then* SendData will work perfectly (don't use parenthesis in the SendData command...won't hurt it, but since it doesn't return anything it's unneeded)
This works for single connection servers. There are several posts around the Forums about multiple connection servers, none of which I remember where they are right now :) If the search function isn't working, I'll post code when my development computer is up and running (it's not now)
What ccoder and everyone else said about waiting for the connection to be OK is true, but the method isn't sound.
Event-driven programming is what Windows and VB are all about...the programmer shouldn't have to enter an infinite loop waiting for something to happen, because when something *does* happen an event will be fired (be it Connect, Error, DataArrival, whatever) and *then* you can take action.
Plus, the infinite loop + DoEvents combination will have the unpleasant side effect of hardlining your CPU (driving your CPU usage to 100%, which in turn causes evil things like Heat to happen :eek: ). The DoEvents ensure other programs get a fair shake, but it is needless heat generation. (I've never baked a chip, and I don't plan to start :) )
csammis,Quote:
Originally posted by csammis
What ccoder and everyone else said about waiting for the connection to be OK is true, but the method isn't sound.
Event-driven programming is what Windows and VB are all about...the programmer shouldn't have to enter an infinite loop waiting for something to happen, because when something *does* happen an event will be fired (be it Connect, Error, DataArrival, whatever) and *then* you can take action.
Plus, the infinite loop + DoEvents combination will have the unpleasant side effect of hardlining your CPU (driving your CPU usage to 100%, which in turn causes evil things like Heat to happen :eek: ). The DoEvents ensure other programs get a fair shake, but it is needless heat generation. (I've never baked a chip, and I don't plan to start :) )
I have to agree with you.
Unfortunately, many new winsock users are using the example provided by this forum: http://161.58.186.98/articles/winsock/ and it is causing them a lot of problems. It has the notorious DoEvents loop. It also lists the Winsock1.Close immediately following the Winsock1.SendData (txtMessage.Text). This has generated countless posts asking why the data isn't getting to the other computer.
FWIW, I always put my connect code in the Form_Load. By the time I'm ready actually send something, the connect should be complete. If it isn't, I have a problem. Next, I always check the winsock state before sending anything and take corrective measures if the connection has died.
I know that a loop isn't to bright to use, but you must use something...
And I'm not to well known with winsock yet but I'm learning every day... :)
The best way to learn something is to start trying to do it and if you want to know how to do something you must find the answer, and on the way to the answer you get many useful new stuff...
I started programming for about an year ago and have learned all by myself, with the help of one book and the internet and examples...
So the best way to learn programming is to start with something big...
Well, what I wrote here above doesn't really belong here but it's what I think so... :)
ccoder, I'm glad to see I'm not the only one who thinks that way :) I agree with putting all the connection in Form_Load, and checking the state of the socket before actually doing anything.
About the DoEvents, "wait code", and the like: I'm working on a large-scale server app right now, and I've done serveral server projects in the past. For the longest time, every time I sent something with the Winsock control I'd put a DoEvents after it (actually, I made a generic routine to send data and have a DoEvents, but that's beside the point)...and sometimes everything worked normally, sometimes the data wouldn't make it to its destination, sometimes apps that interfaced with my server were "flooding" my app with data faster than mine could respond, and for the longest time I couldn't figure out what was happening. Turns out that the DoEvents were actually slowing my app down to the point that non-blocking sockets were acting like blocking. The only thing that made it work sometimes was the amount of things that DoEvents got done (i.e., how much was actually in the event queue that Windows had to process). I removed them and everything was good.
Moral of the story: Yes, wait for time-critical operations (accepting requests, opening/closing sockets), but be conservative in putting DoEvents in for the sake of making sure things happen :)
I have notised myself that the DoEvents command slows things down, but I hate to have my app freeze all when it makes a big thing...
But it seems like the DoEvents loop doesn't do any good when connecting, because it can go on and on and never become connected... (has happened to me sometimes)
But it was very good to read your morale :)