[RESOLVED] winsock - client AND server

[drivenbywhat]

Is it not possible to make a program be both a client & server? I'm new to the winsock control & just finished reading PINO's basic intro. I did the peer-to-peer project for client/server chat. However, I want the program to be both a server & a client so two people don't have to worry about one being the server & one being the client.

I have the code for the program to listen. However, when I put the code for it to make a connection & click the button for that code, it states "invalid operation at current state".

So is it possible to have a program be both a client & server? I think it is and maybe it needs 2 winsock controls? Any help is greatly appreciated.

[Pino]

Hello,

Welcome to winsock , Yes it is possible, I'd recomend the best way to do it would be when booting the ap up it automaticly acts as a server (So the socket is listening) only when the user presses connect does it change to be the client. This would eliminate the need for more than 1 socket. Any problems please ask.

Pino

[opus]

It is possible [I have a application which is doing just that), however I think the user must make a selection in order that the applications acts either server or as a client, unless I missed a point.
For a connection one instance of the software acts as a server, the other instance acts as the clinet. Since there are differences (one listens one a winsock the other connects), the software needs to know in way it should go!

[drivenbywhat]

Pino, I tried what you said but I'm not sure I understood you right because I'm still getting the same error. From what I understand, you want me to put the listening code at the form_load instead of a button. Then have the connect code in the button. This results in the same thing as before. "invalid operation at current state" when I click on connect. This is the code. You'll notice your comments are still there cause I'm still at the practice stage and not coding my actual program yet:

Private Sub cmdconnect_Click()
Winsock.RemoteHost = "192.168.0.2"  ' this is the Ip of the server 127.0.0.1 loops back to your own computer
'when i make one exe, i changed the ip, one for 1pc & 1 for another pc. 
Winsock.RemotePort = 15151  'this is the port it must be the same as the server
'since the programs will be in different pcs, it should be no problem to listen on the same port
Winsock.Connect  ' connect!
End Sub
 
Private Sub Form_Load()
Winsock.LocalPort = 15151 'open the port on the local machine try to use ports between 3000 and 50000
Winsock.Listen ' start listening, simple!
End Sub
 
Private Sub Winsock_ConnectionRequest(ByVal requestID As Long)
Winsock.Close 'this resets our socket ready to accept the incoming connection
Winsock.Accept requestID 'accept the connection!
End Sub
 
Private Sub winsock_DataArrival(ByVal bytesTotal As Long)
 
Dim incommingData As String 'this stores the data we receive
 
Winsock.GetData incommingData ' this stores the data in the variable we set above
 
' now we will display it in the textbox
 
Text2.Text = incommingData
 
End Sub
Private Sub cmdSend_click()
Winsock.SendData Text1.Text ' sends the data in the textbox
 
End Sub

Opus, how would I tell the program to stop acting as a server? I guess how would I tell it to stop listening. Also, doing it that way sort defeats what I want to do, which is not having the user have to worry about being a server or a client. It should be seamless for the most part.

[opus]

If you use. .Listen in the Form_load a .Close as the first thing in ConnectButton_Click event should do it.
Concerning the problem that the user shouldn't care, I'm not sure how to do that.
Each instance would need to know wether another instance is already listening or not. If not the connect button shouldN't be enabled or something like that, but how could the instance know if someone else is listening.
BTW how do you set the IP's and port? Any user input here?

[drivenbywhat]

As far as setting the port, it will be hard coded, with an option to specify it if it's not working. The ip will be inputed in a textbox. Right now I'm just hard coding stuff.

I don't know how the program will know if one control is already listening. That's why I need help, lol.

Pino, where are thou?

[dilettante]

Listening is like plugging a phone into the line so it can accept calls. Until you "pick up" the handset your phone is in "server mode."

Connecting to a server is a bit like dialing the telephone. You'd need to "pick up" first (close the listening socket) before you can "dial" (make a connection request).

If you dial a phone that is not listening then you get a busy or out of service signal back.

There is no magic. You can't pick up the phone without dialing and expect the phone to know who to call.

[ccoder]

This results in the same thing as before. "invalid operation at current state" when I click on connect.

Try setting LocalPort to zero before attempting to connect. The port you were listening on is most likely in an unavailable state. You can check this out by running netstat from a CMD prompt after you get the error message. Setting the LocalPort to zero forces the OS to pick an unused port. Just remember to set LocalPort back to 15151 before going back into listening mode.

I don't know how the program will know if one control is already listening. That's why I need help, lol.

If you follow the suggested steps and switch from a server to a client (stop listening and send a connect request when the user wants to connect to the other end), you will either connect or get an error message like one of:
error 10061 (WSAECONNREFUSED) - there is nothing listening on the remote port. The app may not be running or the winsock control is not listening.
or
error 10064 (WSAEHOSTDOWN) - the remote system is most likely shut down.

[drivenbywhat]

Dilettante, I understand the listen & connect part. But if I must close the "listening" to connect, this will make users have to coordinate which one will be the server n which the client. Isn't there a way to make them client & server without much user interaction?

[dilettante]

As others already said, whenever a user is not "dialing" (or connected) he should be "listening" and able to accept an incoming connection. I'm not sure what there is to coordinate here.

Program starts, it listens. Program wants to connect, it stops listening. Program disconnects, it begins listening again.

Just like hanging up the phone, you can accept new calls.

[drivenbywhat]

Dilettante, for the "coordination" part. This is the scenario. Okay, program starts and it is listening. User clicks connect, which according to you, must close the listening because if not it's off the hook like a phone. Now, suppose both people click connect at the same time. Technically, both programs are not listening anymore because it was closed. So they have to coordinate to make sure only one of them connects and the other doesn't. Unless, I'm still not understanding.

[dilettante]

Oh that's about it. Just like two people trying to dial phones to each other at the same time.

The only alternative is for each user's program to be BOTH server and client simultaneously, i.e. using two Winsock controls. This seems sort of pointless though, the process only takes fractions of a second. How likely are the two "calls" to collide? If so, just drop the connection attempt when you get an error, go back to listening again, wait a small random time, try again.

[drivenbywhat]

Dilattante, okay it seems that it's getting into my head now. If I do it the way suggested here, the users will have to agree on who will connect to who. So start program with listening. As soon as the person to be the one connecting to the other is decided, that person should click the "connect" button and in that code close the listening first. The other user should decide he will be the server, so disable his connect button. Right?

If so, COOL!

PS - I've given every1 here a rating. Opus, I couldn't give you one because I "must spread it around b4 giving it to you again, lol"

[dilettante]

Well if they both start as "server" then one clicks Connect. As soon as the connection is established disable both Connect buttons. Something like that.

When the connection drops both start listening again, enable Connect.

[drivenbywhat]

All right. I'll see how it goes. Thanks.

[opus]

OK that'S the idea, don't check before the connection is made, check it as soon as one of the two connects, at this point it is clear who should be Server.
Make sure that both are listening again and that the connect button is avalaible if the connection is closed!