UDP Functions

[MSLx Fanboy]

Updated to 3.1.1.52. Now getting err#10057 "WSAENOTCONN" on UDPSend() in the client script (see previous post).

WSAENOTCONN

Error Number: 10057

Socket is not connected.

A request to send or receive data was disallowed because the socket

is not connected.

Updated scripts in last post for .52 beta

Edited June 24, 2005 by MSLx Fanboy

[jpm]

Updated to 3.1.1.52.  Now getting err#10057 "WSAENOTCONN" on UDPSend() in the client script (see previous post).

<{POST_SNAPBACK}>

I know , Kurt send some modification but I cannot understand if we are in the right direction.

it looks like we need to learn UDP.

THat's the reason I ask long time ago to have example as I am not an expert on UDP programming

[MSLx Fanboy]

When you get a chance, I know you're probably pulling your hair out pondering over that last thought, but it seems that my server script locks up on me, and won't close (I can't right click the tray icon, Ctrl+Alt+Del is not always fun). I'm wondering if its...um...actually...i haven't a clue

And I added that tiny Func so that only one copy is run at a time of each script...Not much of a change...

Updated 7:12 PM: Added UDPSend in client (had removed in error)

client.au3

server.au3

Edited June 24, 2005 by MSLx Fanboy

[jpm]

When you get a chance, I know you're probably pulling your hair out pondering over that last thought, but it seems that my server script locks up on me, and won't close (I can't right click the tray icon, Ctrl+Alt+Del is not always fun).  I'm wondering if its...um...actually...i haven't a clue

And I added that tiny Func so that only one copy is run at a time of each script...Not much of a change...

<{POST_SNAPBACK}>

I share the ctrl-alt-del I experience with previous script. We certainly does have the right implementation for the server

[/dev/null]

And I added that tiny Func so that only one copy is run at a time of each script...Not much of a change...

server works fine with latest code I'm testing with. Client does not use UDPSend() in the script !??! Is that intentional?

Cheers

Kurt

[MSLx Fanboy]

server works fine with latest code I'm testing with. Client does not use UDPSend() in the script !??! Is that intentional?

Cheers

Kurt

<{POST_SNAPBACK}>

Does it terminate properly when closing it? (server)

:"> I took that out by accident in the last revision to the code...I'll update that within a minute or so :">

Made a few minor changes yet again...still getting the error though

Edited June 24, 2005 by MSLx Fanboy

[/dev/null]

Does it terminate properly when closing it? (server)

There is no way to close the application, as there is no message loop. The only way is to kill the process (task manager). You should extend your script either with HotKeySet() or with a GUI and a message loop, if you want to exit it "gracefully". And I bekieve there is another issues. UDPRecv() seems to "block" the script if there is no data to receive. It simply waits until some data is received. I'll check that....

Cheers

Kurt

[MSLx Fanboy]

That's what I was originally thinking, however I wasn't sure considering GUIGetMsg doesn't wait for a message from a gui if it doesn't happen immediately (thinking it will just loop indef. until a message is received)...

[MSLx Fanboy]

Updated to 3.1.1.53. UDP works nicely now

The only thing is that you have to supply IP Address and Port even though you've already supplied the socket number.

Is it possible to have UDPBind() return an array with the socket number, IP, and port, so that you don't have to pass anything other than the UDPBind return to UDPSend? It makes it much easier when programming so that you don't have to remember all of that information, making mistakes less common in this commands.

$aUDP = UDPBind("127.0.0.1", 65432)

;aUDP[0] = "anything"

;aUDP[1] = $socket number

;aUDP[2] = IP Address

;aUDP[3] = Port Number

Also, if you disconnect the server while the client is still trying to send, how can you tell if the socket is closed?

I've updated the scripts for .53 and included hotkeys, F9 closes the client, F10 closes the server. Also, still have to Ctrl+Alt+Del to cancel the server script.

client.au3

server.au3

Edited June 25, 2005 by MSLx Fanboy

[/dev/null]

The only thing is that you have to supply IP Address and Port even though you've already supplied the socket number.

Yes that's "ugly" but I had no better idea..

Is it possible to have UDPBind() return an array with the socket number, IP, and port, so that you don't have to pass anything other than the UDPBind return to UDPSend?  It makes it much easier when programming so that you don't have to remember all of that information, making mistakes less common in this commands.

Yes that's what jpm suggested too. I guess it's a good idea. This way we can also use that "socket" in the server to send some data to a client. This information comes from recvfrom() and can be used in sendto().

So:

$UDPsocket = UDPBind("127.0.0.1", 65432)

;$UDPsocket[0] = extened error messages ?

;$UDPsocket[1] = socket number

;$UDPsocket[2] = IP Address

;$UDPsocket[3] = Port Number

$UDPsocket = UDPOpen("127.0.0.1", 65432)

;$UDPsocket[0] = extened error messages ?

;$UDPsocket[1] = socket number

;$UDPsocket[2] = IP Address

;$UDPsocket[3] = Port Number

$ret = UDPSend($UDPsocket,$data)

$data = UDPRecv($UDPsocket)

UDP sockets are created in blocking mode by default. I guess we should change that, otherwise the server application will "freeze" until there is some data sent to it.

Also, if you disconnect the server while the client is still trying to send, how can you tell if the socket is closed?

You can't, because there is no "connection" established with UDP. That's one of the differences betwenn TCP and UDP. So, a server does not know if a client ist still "connected". The application protocol has to handle that, e.g. send a keepalive every few seconds to tell the server that your client ist still there and send some kind of QUIT message to your server if your client closes the "connection".

Cheers

Kurt

[MSLx Fanboy]

Hehe, already going into CCNA Semester 4 curriculum, you think I would remember that

[Scripting_For_Fun]

Hi,

I have been working through this thread and got to the point where I wish to run the client on one machine and the server on the other.

I proved communications between the client and server on the same machine.

When moving the client to another machine I can capture the UDP packet on the server machine with a sniffer. It comes in from the LAN just fine with all fields as expected. However the Server script does not respond.

I do not know where else to take this...... any ideas would be much appreciated. I have also tried it in the opposite direction. In this case I was able to use the sniffer to show the packet being generated on the client and being received by the server.

One machine is Win98, the other is XP. Both are on fresh installs of release and beta '84 versions. I do not think it is OS specific as I can see the client working ok and the traffic arriving at the server PC in both directions. There are no firewalls in the way either and both machines are in the same IP subnet.

I had to change the call to UDPSend in the client script but that was not too hard!

Regards.

[Scripting_For_Fun]

Ok, found my problem......

UDPBind(@IPAddress1....... and not

UDPBind(127.0.0.1....... as worked when playing with it on same machine!