UDP Server Sending Back to Client

[livewire]

Any idea why this isn't working? It used to work how I wanted it to on AutoIt v3.2.0.0. The client program should send messages to the server and receive back acknowledgments. It appears that in the current version (3.3.0.0), the server sends to itself with this code.

Any clues?

Note: You have to change the IPs to reflect your computer addresses.

Server:

UDPStartup()

$socket = UDPBind("192.168.1.114", 20000)
If @error <> 0 Then Exit

While 1
    $data = UDPRecv($socket,500)
    If $data <> "" Then
        MsgBox(0, "UDP DATA", $data,1)
        $recv_socket = UDPOpen($socket[2], 20000)
        If @error <> 0 Then Exit
        $status = UDPSend($recv_socket, "Ack")
        UDPCloseSocket($recv_socket)
    EndIf
    sleep(50)
WEnd

Func OnAutoItExit()
    UDPCloseSocket($socket)
    UDPShutdown()
EndFunc

-Livewire

[martin]

You need

UDPStartup()

$socket = UDPBind("192.168.1.114", 20000)
If @error <> 0 Then Exit

While 1
    $data = UDPRecv($socket,500)
    If $data <> "" Then
        MsgBox(0, "UDP DATA", $data,1)
        $recv_socket = UDPOpen("192.168.1.111", 20000);<---------------not $socket[2] which is the IP for the server
        If @error <> 0 Then Exit
        $status = UDPSend($recv_socket, "Ack")
        UDPCloseSocket($recv_socket)
    EndIf
    sleep(50)
WEnd

Func OnAutoItExit()
    UDPCloseSocket($socket)
    UDPShutdown()
EndFunc

[livewire]

I would like the code to automatically figure out where the server is (what IP it is). UDPRecv (called in the server) used to obtain the client's IP in the third index of the returned array.

The point of this example is: If you have a server running and an arbitrary client sends data to it, how do you send data back to that client?

Note: The exact code that I posted used to work as I mentioned in v3.2.0.0. Was the functionality changed for any good reason? Or is it a bug?

-Malachi

Edited March 16, 2009 by livewire

[martin]

I would like the code to automatically figure out where the server is (what IP it is). UDPRecv (called in the server) used to obtain the client's IP in the third index of the returned array.

The point of this example is: If you have a server running and an arbitrary client sends data to it, how do you send data back to that client?

Note: The exact code that I posted used to work as I mentioned in v3.2.0.0. Was the functionality changed for any good reason? Or is it a bug?

-Malachi

A UDP packet is sent with the IP of the sender and the IP of the receiver as well as the data but I don't know how to get those IP address's using AutoIt. Unless someone knows differently it seems like an omission in the UDP functions. I'd be surprised if you are correct about it being available in earlier versions of AutoIt; according to the change log no such alteration was made as far as I can see. Are you able to check your script with 3.2.0.0?

The easiest way is for the sender to include its IP as part of the data.

[livewire]

Yes, I have tried the code with AutoIt v3.2.0.0. It used to work and now it doesn't with the current version of AutoIt.

You can try it with an old version and see:

http://www.autoitscript.com/autoit3/files/archive/autoit/

-Malachi

[martin]

Yes, I have tried the code with AutoIt v3.2.0.0. It used to work and now it doesn't with the current version of AutoIt.

You can try it with an old version and see:

http://www.autoitscript.com/autoit3/files/archive/autoit/

-Malachi

I tried it and you are correct.

When data is received $socket[2] is set to the IP of the sender. When there is no data it is set to "0.0.0.0". That is very much more useful than the current verion of UDPRecv and possibly it was changed in error. Unfortunately it was not documented as a feature as far as I can see so it might not be considered to be a bug. There might have been a reason that it was changed that we don't know about but I would vote for it as a desirable feature. Since the sender's IP is sent with the data packet I think that it is sensible that we should have access to it.

EDIT: I created a feature request for this (ticket #867)

Edited March 17, 2009 by martin

[livewire]

Looks like the feature request was denied.

Anyone know why this functionality was removed? It used to function how I mentioned. I don't know which version removed this functionality, but you can test it by running the code in my first post using AutoIt v3.2.0.0.

This is an old post where I explained to someone how it worked:

http://www.autoitscript.com/forum/index.ph...6432&hl=udp

-Livewire

[jpm]

I don't know if it is the answer but some change occur in array management in 3.2.12.1.

Can you check with 3.2.12.0 version if it was working?

I cannot rerun your script with 192.168.1.11x address in my environment.

3.2.0.0 was deliver in August 2006 I assume you are not refering to a so long regression ...

Thanks for the help.

[martin]

I don't know if it is the answer but some change occur in array management in 3.2.12.1.

Can you check with 3.2.12.0 version if it was working?

I cannot rerun your script with 192.168.1.11x address in my environment.

3.2.0.0 was deliver in August 2006 I assume you are not refering to a so long regression ...

Thanks for the help.

Unless liverwire does it first I'll try it tonight.

[jpm]

Unless liverwire does it first I'll try it tonight.

Thanks again for the help

[martin]

Thanks again for the help

I checked the script with version 3.2.12.0 and with 3.2.12.1

$data = _UDPRecv($recv_soket,500)
ConsoleWrite($recv_socket[2]  & @CRLF);<--- gets set to the IP of the sender with both 3.2.12.0 and 3.2.12.1

I sent data from a PC which had V3.3.0.0 and on that PC

$data = UDPRecv($socket,500)
 ConsoleWrite($socket[2] & @CRLF);<---------3.3.0.0 never shows the sender's IP.(Not like 3.2.12.0 and 3.2.12.1)

[trancexx]

I can confirm martin's results for both 3.2.12.1 and of course 3.3.0.0

[jpm]

I checked the script with version 3.2.12.0 and with 3.2.12.1

$data = _UDPRecv($recv_soket,500)
ConsoleWrite($recv_socket[2]  & @CRLF);<--- gets set to the IP of the sender with both 3.2.12.0 and 3.2.12.1

I sent data from a PC which had V3.3.0.0 and on that PC

$data = UDPRecv($socket,500)
 ConsoleWrite($socket[2] & @CRLF);<---------3.3.0.0 never shows the sender's IP.(Not like 3.2.12.0 and 3.2.12.1)

Thanks

Certainly some modification after 3.2.12.1.

Anyway my concern now is : is port recv is of some usage when using this recv IP?

[martin]

Thanks

Certainly some modification after 3.2.12.1.

Anyway my concern now is : is port recv is of some usage when using this recv IP?

I think so because to reply to the sender which could be one of several senders from the same ip, you need to know the sender's port.

[jpm]

I think so because to reply to the sender which could be one of several senders from the same ip, you need to know the sender's port.

so as Autoit never update parameter pass to builtin function we need to defined a new way of return them with the data.

We will define a Flag 2 with will return and array[0]= data array[1]=ip array[2]=port as suggested by Valik

[martin]

so as Autoit never update parameter pass to builtin function we need to defined a new way of return them with the data.

We will define a Flag 2 with will return and array[0]= data array[1]=ip array[2]=port as suggested by Valik

Sounds good

Thanks jpm and Valik.

[jpm]

Sounds good

Thanks jpm and Valik.

I still have a problem as the return port does not correspond to the one used in UDPSend(). I don't know who is right ...

[martin]

I still have a problem as the return port does not correspond to the one used in UDPSend(). I don't know who is right ...

When you UDPSend the data gets to the correct port and is received so the send port must be handled correctly. Maybe you are reading the source port incorrectly when you receive? Perhaps because the port is an unsigned short integer?

[jpm]

When you UDPSend the data gets to the correct port and is received so the send port must be handled correctly. Maybe you are reading the source port incorrectly when you receive? Perhaps because the port is an unsigned short integer?

The values are return by :

inet_ntoa(remote.sin_addr);

ntohs(remote.sin_port);

The port received is not the one use in the UDPSend. So ???

[martin]

The values are return by :

inet_ntoa(remote.sin_addr);

ntohs(remote.sin_port);

The port received is not the one use in the UDPSend. So ???

Is it possible that the port number is being read correctly but the port number is not correctly entered in the header by _UDPSend?