|
|
Post by Rod on Mar 12, 2020 13:46:45 GMT -5
Yes, don't get confused by the thread. Chris has provided a UDP .dll that works perfectly well. The issue is that you need to know what message to send. Devices can be really picky. That's where we are. This alarm panel is probably one of the hardest devices to "guess" the message format.
|
|
|
|
Post by pandawdy on Mar 12, 2020 18:50:53 GMT -5
Oh no.. I'm not confused. I'm working with a different device and it's message format is very simple. I think Chris's DLL will help a lot.
|
|
|
|
Post by pandawdy on Mar 12, 2020 19:08:30 GMT -5
In this snippet of code from test-udp-client.bas, in the sub UDPConnect, what is "50000"? Is this the port number?
call OpenLBNetDLL
input "press ENTER to begin.";a
connectServer$ = "127.0.0.1"
hSock = UDPConnect(connectServer$, "50000", 0)
if IsSocketInvalid(hSock) then
print "Connect() failed. - ";GetError()
goto [doEnd]
end if
|
|
|
|
Post by Chris Iverson on Mar 12, 2020 19:37:39 GMT -5
Yeah, that's correct. I suppose I should've made that a bit clearer.
|
|
|
|
Post by pandawdy on Mar 14, 2020 12:57:29 GMT -5
Chris.. I don't think I understand how your DLL works. I'm sure it does work.. I'm just not understanding.
I'm using the test_udp_client.bas and attemping to send a message to a device. I know the message is sending correctly.. and the device sends an immediate response on the same port number, but the test_udp_client.bas program doesn't seem to capture the response or just doesn't display it. I'm not sure how to make this happen. I have used the client program example to connect to the server program example.. I know that it works.
A 35 character string is sent to IP address 192.168.1.16 on port 16000. The device will correctly and immediately respond with another 35 character string to my computer on the same port, 16000. How do I capture the response?
call OpenLBNetDLL
input "press ENTER to begin.";a
connectServer$ = "192.168.1.16"
hSock = UDPConnect(connectServer$, "16000", 0)
if IsSocketInvalid(hSock) then
print "Connect() failed. - ";GetError()
goto [doEnd]
end if
print "UDPConnect() successful."
data$ = "*! 09919 100000#"
lenData = len(data$)
print "UDPSend() - ";UDPSend(hSock, data$, lenData)
'goto [doReceive]
[respLoop]
timer 0
print "Waiting for response..."
ret = UDPIsReadAvailable(hSock, 0)
if ret = 0 then
print "Still waiting..."
timer 1000, [respLoop]
wait
end if
[doReceive]
bufLen = 1024
buf$ = space$(bufLen)
num = UDPReceive(hSock, buf$, bufLen)
theError = GetError()
if num = -1 then
if theError = 10101 then
print "Connection closed by server."
else
print "Socket error occurred. - ";dechex$(GetError())
end if
goto [doClose]
end if
'With UDP, if a datagram comes in that is too large for the network stack
'or the specified buffer to handle, the data will be truncated, and the extra data
'is lost. It will still return as many bytes as it can, but it will generate
'the error code WSAEMSGSIZE(10040) while doing so.
'
'While the lost data is unrecoverable, this will at least let the application know
'something was lost.
if theError = 10040 then
print "Received message too large for buffer or other network limit. Datagram truncated, extra data lost."
end if
print "Response - ";left$(buf$, num)
[doClose]
a = UDPClose(hSock)
[doEnd]
call CloseLBNetDLL
|
|
|
|
Post by Chris Iverson on Mar 14, 2020 19:10:44 GMT -5
That... seems like an odd interface. Instead of responding back to the exact connection that sent the data, it responds back to the same IP, but a different port? Note that there are ports on BOTH ends of a connection. The sending port is randomly assigned by your computer when asking it to send data. The target's receive port is 16000, and the data gets sent there. Normally, devices would send back to the IP/Port pair that sent it data, since it already has the connection info by virtue of having received data from that connection.
If it always sends the response back to port 16000 on the initial computer, and not the port the data came from, you'd have to look into the UDP Server example to see how to listen on a specific port on your computer for datagrams.
|
|
|
|
Post by pandawdy on Mar 14, 2020 21:42:22 GMT -5
That... seems like an odd interface. Instead of responding back to the exact connection that sent the data, it responds back to the same IP, but a different port? Note that there are ports on BOTH ends of a connection. The sending port is randomly assigned by your computer when asking it to send data. The target's receive port is 16000, and the data gets sent there. Normally, devices would send back to the IP/Port pair that sent it data, since it already has the connection info by virtue of having received data from that connection. If it always sends the response back to port 16000 on the initial computer, and not the port the data came from, you'd have to look into the UDP Server example to see how to listen on a specific port on your computer for datagrams. Chris, I might have explained it poorly. Just want to be sure.. In the attached photo you can see what happens in Wireshark. My computer is 192.168.1.9. It sends a 35 character string to 192.168.1.16 (the device) on port 16000. The device then immediately responds to the computer on port 16000. Could be I'm just not understanding what needs to happen. I'll look in to the server example you mentioned. ![]()  |
|
|
|
Post by Chris Iverson on Mar 14, 2020 22:29:53 GMT -5
Looks like you got it. And I note that the sending computer is, in fact, sending from port 16000. That's interesting.
Is this capture of the LB app you wrote sending the data? Or is this something else that you're trying to imitate in LB?
|
|
|
|
Post by pandawdy on Mar 14, 2020 23:05:06 GMT -5
Looks like you got it. And I note that the sending computer is, in fact, sending from port 16000. That's interesting. Is this capture of the LB app you wrote sending the data? Or is this something else that you're trying to imitate in LB? I hope to add more functionality to my program, but right now I'm using a different software to initiate a response from the device. My company has official software, but I can add more functions that the official software doesn't have. |
|
|
|
Post by Chris Iverson on Mar 14, 2020 23:20:19 GMT -5
Ok, and out of curiosity, can you get a capture of what is sent between the two devices when you try to send the data from LB?
|
|
|
|
Post by Rod on Mar 15, 2020 3:52:00 GMT -5
Just bumping my gums and trying to learn a bit more. Some of this may be wrong.
output buffer - port port - input buffer
/ \
computer IP X IP device
\ /
input buffer - port port = output buffer
The computer knows the device is on IP 16 and is listening on port 16000.
So it sends a UDP datagram to IP 16 Port 16000 but will use ANY output port to send that message.
According to specs the source (computer), does NOT then listen to a specific input port. In fact it shouldn't be expecting a return message at all.
The device knows the computer is on IP 9, what does it know about the port, according to spec, nothing.
But was it programed to respond to a specific port 16000? Just as the PC was programed to know the device.
So it sends a UDP datagram to IP 9 port 16000 but will use ANY output port to send the message. Just as the computer did.
It sends the "port number" as info to id the destination application?
Is the port just a message identifier to allow the message
to be redirected on receipt to the waiting application?
So do we need to set up a listener application looking for port 16000 messages?
That is what the device is doing is it not?
|
|
|
|
Post by pandawdy on Mar 15, 2020 11:12:59 GMT -5
Ok, and out of curiosity, can you get a capture of what is sent between the two devices when you try to send the data from LB? Chris, Here is what it looks like when the LBnet dll is being used:  |
|
|
|
Post by pandawdy on Mar 15, 2020 11:24:25 GMT -5
Ok, and out of curiosity, can you get a capture of what is sent between the two devices when you try to send the data from LB? I used another piece of code that uses Winsock and it produces the same result.. the port on the sending computer is random.. sent to 16000 on the device. The official company software doesn't do that.. the sending port on the computer is always 16000. But if I can figure out how listen on 16000 for a response then it shouldn't matter. |
|
|
|
Post by pandawdy on Mar 15, 2020 11:35:55 GMT -5
Just bumping my gums and trying to learn a bit more. Some of this may be wrong. output buffer - port port - input buffer / \ computer IP X IP device \ / input buffer - port port = output buffer The computer knows the device is on IP 16 and is listening on port 16000. So it sends a UDP datagram to IP 16 Port 16000 but will use ANY output port to send that message. According to specs the source (computer), does NOT then listen to a specific input port. In fact it shouldn't be expecting a return message at all. The device knows the computer is on IP 9, what does it know about the port, according to spec, nothing. But was it programed to respond to a specific port 16000? Just as the PC was programed to know the device. So it sends a UDP datagram to IP 9 port 16000 but will use ANY output port to send the message. Just as the computer did. It sends the "port number" as info to id the destination application? Is the port just a message identifier to allow the message to be redirected on receipt to the waiting application? So do we need to set up a listener application looking for port 16000 messages? That is what the device is doing is it not? Rod, The way the device is currently setup, it will only respond to my computer, IP address 192.168.1.9, and it will always do it on port 16000. The only thing I can change on the device is the IP used to respond. I can specify what IP it will respond to, or set it to a broadcast ip 255.255.255.255. I'm trying to avoid broadcast so I set it to my own IP. But it will always use port 16000 when responding and will only accept an incoming message on port 16000. I believe you are right... I need to setup something on my PC to listen on port 16000 for a response from the device. |
|
|
|
Post by Rod on Mar 15, 2020 13:11:24 GMT -5
Chris knows a LOT more about this than I do. But every explanation I read tells me that UDP is a connectionless protocol that simply pops a message out on the net. It is targeted at a specific IP and Port, fair enough. But because it is connectionless and because it should not expect a response I get confused.
I would expect a programmed response from a connected device to be hard coded, one IP and one Port (or broadcast). So your device knows that it is talking (responding) to IP 9 Port 16000. That seems to be your setup.
But it should be able to send a message at any time, not simply in immediate response to a received message.
I have purchased a MKR1000 and I am in the throws of getting it onto my wifi network. Then I hope to properly explore UDP messaging. But it isn't turning out to be as simple a process as Arduino would have me believe.
Where would we be without Chris's expertise, these youngsters!
|
|
