Reply by "Ste...@yahoo.com [rabbit-semi]"●August 3, 20162016-08-03
Thanks for the information. I did just what you suggested and it seems to
work.
Regarding wireshark I have some new information. The problem with
capturing multicast packets may not have been a wireshark issue. I ran into
someone else that had the same problem, and he determined that the
multicast port number had to be opened on the PC before wireshark could
capture.
He used the following Python 3 script to open the port:
#!/usr/bin/env python
import socket
import structMCAST_GRP = '224.0.100.100'
MCAST_PORT = 52200sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM,
socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('', MCAST_PORT)) # use MCAST_GRP instead of
'' to listen only
# to MCAST_GRP, not all groups on MCAST_PORT
mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP),
socket.INADDR_ANY)sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP,
mreq)while True:
print(sock.recv(10240))
From: "Tom Collins t...@tomlogic.com [rabbit-semi]"
To: r...
Sent: Tuesday, August 2, 2016 4:47 PM
Subject: Re: [rabbit-semi] Multicast
Steve,
Back from vacation and wanting to follow up on your message. I'm
looking through Dynamic C's TCP/IP stack and have the following to
report:
* MAX_UDP_SOCKET_BUFFERS should be equal to the number of UDP sockets
you're opening. There's no benefit to setting it higher than the
number of sockets -- it's used to store copies of the udp_Socket pointer
passed into udp_open().
* The stack allocates UDP_BUF_SIZE of space for each of the
MAX_UDP_SOCKET_BUFFERS.
* As best as I can tell, the UDP sockets each get UDP_BUF_SIZE bytes. This
is good in that a single UDP socket can't starve out other sockets, but it
requires you to keep up with datagrams.
* So, I would advise on setting MAX_UDP_SOCKET_BUFFERS based on how many
simultaneous UDP sockets you'll have open, and UDP_BUF_SIZE based on
how much data you expect to receive between calls to udp_recv().
* If you have just one UDP socket that requires a larger buffer, consider using
udp_extopen() to give it a large buffer so you don't waste space by over
allocating buffers (via UDP_BUF_SIZE) for your other UDP sockets.
Let me know if you still have any outstanding questions on how the UDP sockets
work in Dynamic C, or if the issues you saw were caused by the Wireshark capture
bugs you mentioned in another message.
-Tom
On Jul 22, 2016, at 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi]
wrote:
Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I was asking
aboutthe ratio of sockets to buffers. Could I get away with a single UDP
socket and say 5 buffers withoutdropping datagrams?
#yiv8089521912 #yiv8089521912 -- #yiv8089521912ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8089521912
#yiv8089521912ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8089521912
#yiv8089521912ygrp-mkp #yiv8089521912hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8089521912 #yiv8089521912ygrp-mkp #yiv8089521912ads
{margin-bottom:10px;}#yiv8089521912 #yiv8089521912ygrp-mkp .yiv8089521912ad
{padding:0 0;}#yiv8089521912 #yiv8089521912ygrp-mkp .yiv8089521912ad p
{margin:0;}#yiv8089521912 #yiv8089521912ygrp-mkp .yiv8089521912ad a
{color:#0000ff;text-decoration:none;}#yiv8089521912 #yiv8089521912ygrp-sponsor
#yiv8089521912ygrp-lc {font-family:Arial;}#yiv8089521912
#yiv8089521912ygrp-sponsor #yiv8089521912ygrp-lc #yiv8089521912hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8089521912
#yiv8089521912ygrp-sponsor #yiv8089521912ygrp-lc .yiv8089521912ad
{margin-bottom:10px;padding:0 0;}#yiv8089521912 #yiv8089521912actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8089521912
#yiv8089521912activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8089521912
#yiv8089521912activity span {font-weight:700;}#yiv8089521912
#yiv8089521912activity span:first-child
{text-transform:uppercase;}#yiv8089521912 #yiv8089521912activity span a
{color:#5085b6;text-decoration:none;}#yiv8089521912 #yiv8089521912activity span
span {color:#ff7900;}#yiv8089521912 #yiv8089521912activity span
.yiv8089521912underline {text-decoration:underline;}#yiv8089521912
.yiv8089521912attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv8089521912 .yiv8089521912attach div a
{text-decoration:none;}#yiv8089521912 .yiv8089521912attach img
{border:none;padding-right:5px;}#yiv8089521912 .yiv8089521912attach label
{display:block;margin-bottom:5px;}#yiv8089521912 .yiv8089521912attach label a
{text-decoration:none;}#yiv8089521912 blockquote {margin:0 0 0
4px;}#yiv8089521912 .yiv8089521912bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8089521912
.yiv8089521912bold a {text-decoration:none;}#yiv8089521912 dd.yiv8089521912last
p a {font-family:Verdana;font-weight:700;}#yiv8089521912 dd.yiv8089521912last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8089521912
dd.yiv8089521912last p span.yiv8089521912yshortcuts
{margin-right:0;}#yiv8089521912 div.yiv8089521912attach-table div div a
{text-decoration:none;}#yiv8089521912 div.yiv8089521912attach-table
{width:400px;}#yiv8089521912 div.yiv8089521912file-title a, #yiv8089521912
div.yiv8089521912file-title a:active, #yiv8089521912 div.yiv8089521912file-title
a:hover, #yiv8089521912 div.yiv8089521912file-title a:visited
{text-decoration:none;}#yiv8089521912 div.yiv8089521912photo-title a,
#yiv8089521912 div.yiv8089521912photo-title a:active, #yiv8089521912
div.yiv8089521912photo-title a:hover, #yiv8089521912
div.yiv8089521912photo-title a:visited {text-decoration:none;}#yiv8089521912
div#yiv8089521912ygrp-mlmsg #yiv8089521912ygrp-msg p a
span.yiv8089521912yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8089521912
.yiv8089521912green {color:#628c2a;}#yiv8089521912 .yiv8089521912MsoNormal
{margin:0 0 0 0;}#yiv8089521912 o {font-size:0;}#yiv8089521912
#yiv8089521912photos div {float:left;width:72px;}#yiv8089521912
#yiv8089521912photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv8089521912
#yiv8089521912photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8089521912
#yiv8089521912reco-category {font-size:77%;}#yiv8089521912
#yiv8089521912reco-desc {font-size:77%;}#yiv8089521912 .yiv8089521912replbq
{margin:4px;}#yiv8089521912 #yiv8089521912ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv8089521912 #yiv8089521912ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8089521912
#yiv8089521912ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8089521912
#yiv8089521912ygrp-mlmsg select, #yiv8089521912 input, #yiv8089521912 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv8089521912
#yiv8089521912ygrp-mlmsg pre, #yiv8089521912 code {font:115%
monospace;}#yiv8089521912 #yiv8089521912ygrp-mlmsg *
{line-height:1.22em;}#yiv8089521912 #yiv8089521912ygrp-mlmsg #yiv8089521912logo
{padding-bottom:10px;}#yiv8089521912 #yiv8089521912ygrp-msg p a
{font-family:Verdana;}#yiv8089521912 #yiv8089521912ygrp-msg
p#yiv8089521912attach-count span {color:#1E66AE;font-weight:700;}#yiv8089521912
#yiv8089521912ygrp-reco #yiv8089521912reco-head
{color:#ff7900;font-weight:700;}#yiv8089521912 #yiv8089521912ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv8089521912 #yiv8089521912ygrp-sponsor
#yiv8089521912ov li a {font-size:130%;text-decoration:none;}#yiv8089521912
#yiv8089521912ygrp-sponsor #yiv8089521912ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv8089521912
#yiv8089521912ygrp-sponsor #yiv8089521912ov ul {margin:0;padding:0 0 0
8px;}#yiv8089521912 #yiv8089521912ygrp-text {font-family:Georgia;}#yiv8089521912
#yiv8089521912ygrp-text p {margin:0 0 1em 0;}#yiv8089521912
#yiv8089521912ygrp-text tt {font-size:120%;}#yiv8089521912
#yiv8089521912ygrp-vital ul li:last-child {border-right:none
!important;}#yiv8089521912
Reply by "Tom...@tomlogic.com [rabbit-semi]"●August 2, 20162016-08-02
Steve,
Back from vacation and wanting to follow up on your message. I'm looking
through Dynamic C's TCP/IP stack and have the following to report:
* MAX_UDP_SOCKET_BUFFERS should be equal to the number of UDP sockets
you're opening. There's no benefit to setting it higher than the
number of sockets -- it's used to store copies of the udp_Socket pointer
passed into udp_open().
* The stack allocates UDP_BUF_SIZE of space for each of the
MAX_UDP_SOCKET_BUFFERS.
* As best as I can tell, the UDP sockets each get UDP_BUF_SIZE bytes. This is
good in that a single UDP socket can't starve out other sockets, but it
requires you to keep up with datagrams.
* So, I would advise on setting MAX_UDP_SOCKET_BUFFERS based on how many
simultaneous UDP sockets you'll have open, and UDP_BUF_SIZE based on how
much data you expect to receive between calls to udp_recv().
* If you have just one UDP socket that requires a larger buffer, consider using
udp_extopen() to give it a large buffer so you don't waste space by over
allocating buffers (via UDP_BUF_SIZE) for your other UDP sockets.
Let me know if you still have any outstanding questions on how the UDP sockets
work in Dynamic C, or if the issues you saw were caused by the Wireshark capture
bugs you mentioned in another message.
-Tom
On Jul 22, 2016, at 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi]
wrote:
> Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I
know I need them. I was asking about
> the ratio of sockets to buffers. Could I get away with a single UDP socket
and say 5 buffers without
> dropping datagrams?
>
Reply by "Tom...@tomlogic.com [rabbit-semi]"●July 27, 20162016-07-27
Steve,
Good to know. I recently ran into trouble with Wireshark as well, and was
really confused about what I was seeing. I was trying to monitor packets going
in/out of an Ubuntu VM. One day, everything was working properly. A few days
later, it was only capturing one side of the UDP connections.
If I need to capture again, I'll be sure to restart Wireshark after
starting everything. I thought I had tried doing that, but maybe I was just
trying it after launching the VM.
-Tom
On Jul 27, 2016, at 12:48 PM, Steve Trigero s...@yahoo.com [rabbit-semi]
wrote:
> Well, it turns out to be a wireshark issue. This
latest version of wireshark is not as user friendly as it used to be.
>
> So check this out. I have an RM3900 setup to send a UDP datagram every 500ms
to either a Multicast IP or to a
> Broadcast IP. I send a command to the Rabbit telling it which protocol to
use.
>
> I set the Rabbit to use broadcast then start wireshark. It captures all the
broadcast traffic. I tell the Rabbit to switch
> to using Multicast and wireshark goes silent. I close wireshark and reopen it.
Presto! The multicast datagrams show
> up in the capture. Switch back to sending broadcasts. Wireshark goes silent
again. Close and reopen, and theystart
> showing up again.
>
> So the Rabbit appears to be working, wireshark not so much.
>
> Steve
Reply by "Ste...@yahoo.com [rabbit-semi]"●July 27, 20162016-07-27
Well, it turns out to be a wireshark issue. This latest version of wireshark is
not as user friendly as it used to be.
So check this out. I have an RM3900 setup to send a UDP datagram every
500ms to either a Multicast IP or to a Broadcast IP. I send a command to the
Rabbit telling it which protocol to use.
I set the Rabbit to use broadcast then start wireshark. It captures all the
broadcast traffic. I tell the Rabbit to switch to using Multicast and
wireshark goes silent. I close wireshark and reopen it. Presto! The
multicast datagrams show up in the capture. Switch back to sending broadcasts.
Wireshark goes silent again. Close and reopen, and they start showing up
again.
So the Rabbit appears to be working, wireshark not so much.
Steve
From: "Steve Trigero s...@yahoo.com [rabbit-semi]"
To: "r..."
Sent: Tuesday, July 26, 2016 2:55 PM
Subject: Re: [rabbit-semi] Multicast
I just noticed that the one multicast datagram that wireshark captures
has no data. Yet udp_send keeps reportingthat it is sending 111 bytes with each
call.
I'm beginning to think the datagram wireshark captured is not really
my datagram, but something the Rabbit librarysent, possibly as part
of initialization. The "Info" description in wireshark for the datagram is
"Membership Report Group 224.0.100.100".
Steve
From: "Steve Trigero s...@yahoo.com [rabbit-semi]"
To: "r..."
Sent: Tuesday, July 26, 2016 11:18 AM
Subject: Re: [rabbit-semi] Multicast
I set the number of buffers equal to the number of UDP sockets.
5-sockets, 5-buffers.
I'm using one socket to send a multicast datagram twice a second to ip
224.0.100.100. Using wireshark, I only see one datagram sent. When I use
broadcast, the datagrams are constantly scrolling through the window.
I stepped through the code and it is constantly calling udp_send(), and udp_send
is returning 111, meaning it sent 111 bytes.
I enabled UDP_VERBOSE, and set debug_udp to 7. This is the output:
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
UDP: got pkt 0AFA0556:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0579:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0554:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0589:2099 -> FFFFFFFF:2100 payload4
i/f=0
UDP: ...using ARP table
entry
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
The same set of print statements repeats. You can see the receipt of a broadcast
datagram sent by another piece of equipment at the 8th printout.
Each time I restart the program, wireshark shows one multicast datagram being
sent. Do you suppose this is a wireshark configuration issue, because the
Rabbit appears to be sending the packets?
I'm using an RCM3900 with DC 9.62.
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]"
To: r...
Sent: Monday, July 25, 2016 2:45 PM
Subject: Re: [rabbit-semi] Multicast
That first drop might be something to do with timing for setting up
the arp table with resolve information or something. Or, the debugger
slows things down enough for an arp to go before things get noticed.
As far as number of buffers, I think there is just a 1-to-1 correspondence
between udp sockets and udp buffers. Each socket you open in some way
needs space to stick incoming datagrams. I don't think multiple
buffers are used by the same socket. That's just a chunk of space
where an incoming datagram gets copied until you "recv" it. So,
you'll just have to make sure that you "recv" before that buffer space gets
filled up. The default is 4096 (UDP_BUF_SIZE). With 150 byte
datagrams, you can probably put a bunch in there before you start dropping
them. You might want to put some stats somewhere to track dropped packets
based on not enough space as work out your system design.
You could also use a custom datahandler on that multicast socket so you
wouldn't use the system allocated udp buffer space. I think you get
access to the ethernet packet directly that way and can do what you want with
it.
-- Dave
On 7/22/2016 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
Ah, you're right about the debug_on variable. I forgot about
that. In any case, it's working for now.
Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I was
asking about the ratio of sockets to buffers. Could I get away with a
single UDP socket and say 5 buffers without dropping datagrams?
This comes up because I am experimenting with Multicast, which I've not
used before. Normally, I open 3 sockets with REMIP and PORT set to -1, so they
will accept datagrams from any host, whether Broadcast or directed. And I have
MAX_UDP_SOCKET_BUFFERS set to 4.
To add Multicast, I needed a socket that was opened with REMIP set to a
Multicast IP. It's when I added this new socket is when the issue of losing
the first datagram appeared, and has now disappeared. When I saw the
dropped/lost first packet, I thought it might be related to the comment for
udp_extopen() in the manual that says:
"If remip is non-zero, then the process of resolving the
correct destination
hardware address is started. Datagrams cannot be sent until
sock_resolved()
returns TRUE. If you attempt to send datagrams before this,
then the
datagrams may not get sent."
But when I ran the debugger, it went away.
So now I have 4 UDP sockets, with one being for Multicast, and I increased the
buffers to 6. Should I have more Multicast sockets or less Broadcast sockets?
Could I get away with one socket of each?
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]" mailto:r...
To: r...
Sent: Friday, July 22, 2016 7:42 AM
Subject: Re: [rabbit-semi] Multicast
Along with UDP_VERBOSE, set the global debug_on to something like
7 on startup. Should produce more debug output.
And when you mention "UDP sockets" and "number of UDP buffers", are you
actually talking about some of the macros (like MAX_UDP_SOCKET_BUFFERS?)
Cuz you do need buffers to hold your packets (unless you alloc and supply your
own to the udp handler code.) I don't believe there is a limitation
to the number of udp sockets? Been a while though since I was in there. --
Dave
On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
UDP_VERBOSE doesn't do anything. There is no output when
it's defined. I'm using your updated network library, so maybe
something happened there.
In any case, after I ran my code in the debugger, it started working. So I
recompiled without debug code enabled and reloaded the program, and now it works
every time. Scary.
Slight change of subject.
First, what's the relationship between the number of UDP
sockets and number of UDP buffers? Since UDP is connectionless, a
socket for each potential device that may send a datagram is unnecessary.
But does that mean I could have one socket with a bunch of buffers? A further
explanation is, in a system we typically have 5 sub-systems, with each
sub-system sending a broadcast UDP datagram of its status twice a second. The
datagrams are around 150 bytes each. Each sub-system reads the datagrams and
collects whatever information it needs from the datagrams. So if there is only
one UDP socket and the Rabbit is processing one datagram when another one
arrives, or even two datagrams arrive, do the new datagrams get put
into unused buffers or are they lost because there is not an
unused socket available?
Steve
From: "Tom Collins t...@tomlogic.com [rabbit-semi]" mailto:r...
To: r...
Sent: Thursday, July 21, 2016 11:28 AM
Subject: Re: [rabbit-semi] Multicast
Do you see the packet come in if you define UDP_VERBOSE in your
program?
I've seen instances where the first response to a UDP datagram
doesn't go out due to needing to ARP the IP address, but there are some
ways around that (telling the stack to use the MAC from the received frame).
I'm on vacation through the end of the month, so don't have access
to code I can share, but I'm curious as to whether the datagram moves
through the TCP/IP stack at all.
-Tom
On Jul 21, 2016, at 12:23 PM, s...@yahoo.com [rabbit-semi] wrote:
I added a Multicast socket to my RCM3900 application, using IP
239.255.255.255. I have a total of 4 UDP sockets open, 3 are opened with
an REMIP and Port of -1, and one is opened with the Multicast IP and port
2100. And Max UDP Buffers is set to 5.
After boot-up, the first UDP datagram to the module is not responded to. It
doesn't matter if the datagram was a broadcast or a multicast. The first
one is not responded to. After the first one, then it starts responding to both
broadcasts and multicasts.
Is there something else I need to do to get that first datagram to work?
I'm using DC 9.62. .
#yiv1363010438 #yiv1363010438 -- #yiv1363010438ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1363010438
#yiv1363010438ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1363010438
#yiv1363010438ygrp-mkp #yiv1363010438hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1363010438 #yiv1363010438ygrp-mkp #yiv1363010438ads
{margin-bottom:10px;}#yiv1363010438 #yiv1363010438ygrp-mkp .yiv1363010438ad
{padding:0 0;}#yiv1363010438 #yiv1363010438ygrp-mkp .yiv1363010438ad p
{margin:0;}#yiv1363010438 #yiv1363010438ygrp-mkp .yiv1363010438ad a
{color:#0000ff;text-decoration:none;}#yiv1363010438 #yiv1363010438ygrp-sponsor
#yiv1363010438ygrp-lc {font-family:Arial;}#yiv1363010438
#yiv1363010438ygrp-sponsor #yiv1363010438ygrp-lc #yiv1363010438hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1363010438
#yiv1363010438ygrp-sponsor #yiv1363010438ygrp-lc .yiv1363010438ad
{margin-bottom:10px;padding:0 0;}#yiv1363010438 #yiv1363010438actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1363010438
#yiv1363010438activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1363010438
#yiv1363010438activity span {font-weight:700;}#yiv1363010438
#yiv1363010438activity span:first-child
{text-transform:uppercase;}#yiv1363010438 #yiv1363010438activity span a
{color:#5085b6;text-decoration:none;}#yiv1363010438 #yiv1363010438activity span
span {color:#ff7900;}#yiv1363010438 #yiv1363010438activity span
.yiv1363010438underline {text-decoration:underline;}#yiv1363010438
.yiv1363010438attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv1363010438 .yiv1363010438attach div a
{text-decoration:none;}#yiv1363010438 .yiv1363010438attach img
{border:none;padding-right:5px;}#yiv1363010438 .yiv1363010438attach label
{display:block;margin-bottom:5px;}#yiv1363010438 .yiv1363010438attach label a
{text-decoration:none;}#yiv1363010438 blockquote {margin:0 0 0
4px;}#yiv1363010438 .yiv1363010438bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1363010438
.yiv1363010438bold a {text-decoration:none;}#yiv1363010438 dd.yiv1363010438last
p a {font-family:Verdana;font-weight:700;}#yiv1363010438 dd.yiv1363010438last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1363010438
dd.yiv1363010438last p span.yiv1363010438yshortcuts
{margin-right:0;}#yiv1363010438 div.yiv1363010438attach-table div div a
{text-decoration:none;}#yiv1363010438 div.yiv1363010438attach-table
{width:400px;}#yiv1363010438 div.yiv1363010438file-title a, #yiv1363010438
div.yiv1363010438file-title a:active, #yiv1363010438 div.yiv1363010438file-title
a:hover, #yiv1363010438 div.yiv1363010438file-title a:visited
{text-decoration:none;}#yiv1363010438 div.yiv1363010438photo-title a,
#yiv1363010438 div.yiv1363010438photo-title a:active, #yiv1363010438
div.yiv1363010438photo-title a:hover, #yiv1363010438
div.yiv1363010438photo-title a:visited {text-decoration:none;}#yiv1363010438
div#yiv1363010438ygrp-mlmsg #yiv1363010438ygrp-msg p a
span.yiv1363010438yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1363010438
.yiv1363010438green {color:#628c2a;}#yiv1363010438 .yiv1363010438MsoNormal
{margin:0 0 0 0;}#yiv1363010438 o {font-size:0;}#yiv1363010438
#yiv1363010438photos div {float:left;width:72px;}#yiv1363010438
#yiv1363010438photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv1363010438
#yiv1363010438photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv1363010438
#yiv1363010438reco-category {font-size:77%;}#yiv1363010438
#yiv1363010438reco-desc {font-size:77%;}#yiv1363010438 .yiv1363010438replbq
{margin:4px;}#yiv1363010438 #yiv1363010438ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv1363010438 #yiv1363010438ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv1363010438
#yiv1363010438ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv1363010438
#yiv1363010438ygrp-mlmsg select, #yiv1363010438 input, #yiv1363010438 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv1363010438
#yiv1363010438ygrp-mlmsg pre, #yiv1363010438 code {font:115%
monospace;}#yiv1363010438 #yiv1363010438ygrp-mlmsg *
{line-height:1.22em;}#yiv1363010438 #yiv1363010438ygrp-mlmsg #yiv1363010438logo
{padding-bottom:10px;}#yiv1363010438 #yiv1363010438ygrp-msg p a
{font-family:Verdana;}#yiv1363010438 #yiv1363010438ygrp-msg
p#yiv1363010438attach-count span {color:#1E66AE;font-weight:700;}#yiv1363010438
#yiv1363010438ygrp-reco #yiv1363010438reco-head
{color:#ff7900;font-weight:700;}#yiv1363010438 #yiv1363010438ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv1363010438 #yiv1363010438ygrp-sponsor
#yiv1363010438ov li a {font-size:130%;text-decoration:none;}#yiv1363010438
#yiv1363010438ygrp-sponsor #yiv1363010438ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv1363010438
#yiv1363010438ygrp-sponsor #yiv1363010438ov ul {margin:0;padding:0 0 0
8px;}#yiv1363010438 #yiv1363010438ygrp-text {font-family:Georgia;}#yiv1363010438
#yiv1363010438ygrp-text p {margin:0 0 1em 0;}#yiv1363010438
#yiv1363010438ygrp-text tt {font-size:120%;}#yiv1363010438
#yiv1363010438ygrp-vital ul li:last-child {border-right:none
!important;}#yiv1363010438
Reply by "Ste...@yahoo.com [rabbit-semi]"●July 26, 20162016-07-26
I just noticed that the one multicast datagram that wireshark captures has no
data. Yet udp_send keeps reportingthat it is sending 111 bytes with each
call.
I'm beginning to think the datagram wireshark captured is not really
my datagram, but something the Rabbit librarysent, possibly as part
of initialization. The "Info" description in wireshark for the datagram is
"Membership Report Group 224.0.100.100".
Steve
From: "Steve Trigero s...@yahoo.com [rabbit-semi]"
To: "r..."
Sent: Tuesday, July 26, 2016 11:18 AM
Subject: Re: [rabbit-semi] Multicast
I set the number of buffers equal to the number of UDP sockets.
5-sockets, 5-buffers.
I'm using one socket to send a multicast datagram twice a second to ip
224.0.100.100. Using wireshark, I only see one datagram sent. When I use
broadcast, the datagrams are constantly scrolling through the window.
I stepped through the code and it is constantly calling udp_send(), and udp_send
is returning 111, meaning it sent 111 bytes.
I enabled UDP_VERBOSE, and set debug_udp to 7. This is the output:
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
UDP: got pkt 0AFA0556:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0579:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0554:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0589:2099 -> FFFFFFFF:2100 payload4
i/f=0
UDP: ...using ARP table
entry
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
The same set of print statements repeats. You can see the receipt of a broadcast
datagram sent by another piece of equipment at the 8th printout.
Each time I restart the program, wireshark shows one multicast datagram being
sent. Do you suppose this is a wireshark configuration issue, because the
Rabbit appears to be sending the packets?
I'm using an RCM3900 with DC 9.62.
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]"
To: r...
Sent: Monday, July 25, 2016 2:45 PM
Subject: Re: [rabbit-semi] Multicast
That first drop might be something to do with timing for setting up
the arp table with resolve information or something. Or, the debugger
slows things down enough for an arp to go before things get noticed.
As far as number of buffers, I think there is just a 1-to-1 correspondence
between udp sockets and udp buffers. Each socket you open in some way
needs space to stick incoming datagrams. I don't think multiple
buffers are used by the same socket. That's just a chunk of space
where an incoming datagram gets copied until you "recv" it. So,
you'll just have to make sure that you "recv" before that buffer space gets
filled up. The default is 4096 (UDP_BUF_SIZE). With 150 byte
datagrams, you can probably put a bunch in there before you start dropping
them. You might want to put some stats somewhere to track dropped packets
based on not enough space as work out your system design.
You could also use a custom datahandler on that multicast socket so you
wouldn't use the system allocated udp buffer space. I think you get
access to the ethernet packet directly that way and can do what you want with
it.
-- Dave
On 7/22/2016 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
Ah, you're right about the debug_on variable. I forgot about
that. In any case, it's working for now.
Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I was
asking about the ratio of sockets to buffers. Could I get away with a
single UDP socket and say 5 buffers without dropping datagrams?
This comes up because I am experimenting with Multicast, which I've not
used before. Normally, I open 3 sockets with REMIP and PORT set to -1, so they
will accept datagrams from any host, whether Broadcast or directed. And I have
MAX_UDP_SOCKET_BUFFERS set to 4.
To add Multicast, I needed a socket that was opened with REMIP set to a
Multicast IP. It's when I added this new socket is when the issue of losing
the first datagram appeared, and has now disappeared. When I saw the
dropped/lost first packet, I thought it might be related to the comment for
udp_extopen() in the manual that says:
"If remip is non-zero, then the process of resolving the
correct destination
hardware address is started. Datagrams cannot be sent until
sock_resolved()
returns TRUE. If you attempt to send datagrams before this,
then the
datagrams may not get sent."
But when I ran the debugger, it went away.
So now I have 4 UDP sockets, with one being for Multicast, and I increased the
buffers to 6. Should I have more Multicast sockets or less Broadcast sockets?
Could I get away with one socket of each?
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]" mailto:r...
To: r...
Sent: Friday, July 22, 2016 7:42 AM
Subject: Re: [rabbit-semi] Multicast
Along with UDP_VERBOSE, set the global debug_on to something like
7 on startup. Should produce more debug output.
And when you mention "UDP sockets" and "number of UDP buffers", are you
actually talking about some of the macros (like MAX_UDP_SOCKET_BUFFERS?)
Cuz you do need buffers to hold your packets (unless you alloc and supply your
own to the udp handler code.) I don't believe there is a limitation
to the number of udp sockets? Been a while though since I was in there. --
Dave
On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
UDP_VERBOSE doesn't do anything. There is no output when
it's defined. I'm using your updated network library, so maybe
something happened there.
In any case, after I ran my code in the debugger, it started working. So I
recompiled without debug code enabled and reloaded the program, and now it works
every time. Scary.
Slight change of subject.
First, what's the relationship between the number of UDP
sockets and number of UDP buffers? Since UDP is connectionless, a
socket for each potential device that may send a datagram is unnecessary.
But does that mean I could have one socket with a bunch of buffers? A further
explanation is, in a system we typically have 5 sub-systems, with each
sub-system sending a broadcast UDP datagram of its status twice a second. The
datagrams are around 150 bytes each. Each sub-system reads the datagrams and
collects whatever information it needs from the datagrams. So if there is only
one UDP socket and the Rabbit is processing one datagram when another one
arrives, or even two datagrams arrive, do the new datagrams get put
into unused buffers or are they lost because there is not an
unused socket available?
Steve
From: "Tom Collins t...@tomlogic.com [rabbit-semi]" mailto:r...
To: r...
Sent: Thursday, July 21, 2016 11:28 AM
Subject: Re: [rabbit-semi] Multicast
Do you see the packet come in if you define UDP_VERBOSE in your
program?
I've seen instances where the first response to a UDP datagram
doesn't go out due to needing to ARP the IP address, but there are some
ways around that (telling the stack to use the MAC from the received frame).
I'm on vacation through the end of the month, so don't have access
to code I can share, but I'm curious as to whether the datagram moves
through the TCP/IP stack at all.
-Tom
On Jul 21, 2016, at 12:23 PM, s...@yahoo.com [rabbit-semi] wrote:
I added a Multicast socket to my RCM3900 application, using IP
239.255.255.255. I have a total of 4 UDP sockets open, 3 are opened with
an REMIP and Port of -1, and one is opened with the Multicast IP and port
2100. And Max UDP Buffers is set to 5.
After boot-up, the first UDP datagram to the module is not responded to. It
doesn't matter if the datagram was a broadcast or a multicast. The first
one is not responded to. After the first one, then it starts responding to both
broadcasts and multicasts.
Is there something else I need to do to get that first datagram to work?
I'm using DC 9.62. .
#yiv1702348662 #yiv1702348662 -- #yiv1702348662ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1702348662
#yiv1702348662ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1702348662
#yiv1702348662ygrp-mkp #yiv1702348662hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1702348662 #yiv1702348662ygrp-mkp #yiv1702348662ads
{margin-bottom:10px;}#yiv1702348662 #yiv1702348662ygrp-mkp .yiv1702348662ad
{padding:0 0;}#yiv1702348662 #yiv1702348662ygrp-mkp .yiv1702348662ad p
{margin:0;}#yiv1702348662 #yiv1702348662ygrp-mkp .yiv1702348662ad a
{color:#0000ff;text-decoration:none;}#yiv1702348662 #yiv1702348662ygrp-sponsor
#yiv1702348662ygrp-lc {font-family:Arial;}#yiv1702348662
#yiv1702348662ygrp-sponsor #yiv1702348662ygrp-lc #yiv1702348662hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1702348662
#yiv1702348662ygrp-sponsor #yiv1702348662ygrp-lc .yiv1702348662ad
{margin-bottom:10px;padding:0 0;}#yiv1702348662 #yiv1702348662actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1702348662
#yiv1702348662activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1702348662
#yiv1702348662activity span {font-weight:700;}#yiv1702348662
#yiv1702348662activity span:first-child
{text-transform:uppercase;}#yiv1702348662 #yiv1702348662activity span a
{color:#5085b6;text-decoration:none;}#yiv1702348662 #yiv1702348662activity span
span {color:#ff7900;}#yiv1702348662 #yiv1702348662activity span
.yiv1702348662underline {text-decoration:underline;}#yiv1702348662
.yiv1702348662attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv1702348662 .yiv1702348662attach div a
{text-decoration:none;}#yiv1702348662 .yiv1702348662attach img
{border:none;padding-right:5px;}#yiv1702348662 .yiv1702348662attach label
{display:block;margin-bottom:5px;}#yiv1702348662 .yiv1702348662attach label a
{text-decoration:none;}#yiv1702348662 blockquote {margin:0 0 0
4px;}#yiv1702348662 .yiv1702348662bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1702348662
.yiv1702348662bold a {text-decoration:none;}#yiv1702348662 dd.yiv1702348662last
p a {font-family:Verdana;font-weight:700;}#yiv1702348662 dd.yiv1702348662last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1702348662
dd.yiv1702348662last p span.yiv1702348662yshortcuts
{margin-right:0;}#yiv1702348662 div.yiv1702348662attach-table div div a
{text-decoration:none;}#yiv1702348662 div.yiv1702348662attach-table
{width:400px;}#yiv1702348662 div.yiv1702348662file-title a, #yiv1702348662
div.yiv1702348662file-title a:active, #yiv1702348662 div.yiv1702348662file-title
a:hover, #yiv1702348662 div.yiv1702348662file-title a:visited
{text-decoration:none;}#yiv1702348662 div.yiv1702348662photo-title a,
#yiv1702348662 div.yiv1702348662photo-title a:active, #yiv1702348662
div.yiv1702348662photo-title a:hover, #yiv1702348662
div.yiv1702348662photo-title a:visited {text-decoration:none;}#yiv1702348662
div#yiv1702348662ygrp-mlmsg #yiv1702348662ygrp-msg p a
span.yiv1702348662yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1702348662
.yiv1702348662green {color:#628c2a;}#yiv1702348662 .yiv1702348662MsoNormal
{margin:0 0 0 0;}#yiv1702348662 o {font-size:0;}#yiv1702348662
#yiv1702348662photos div {float:left;width:72px;}#yiv1702348662
#yiv1702348662photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv1702348662
#yiv1702348662photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv1702348662
#yiv1702348662reco-category {font-size:77%;}#yiv1702348662
#yiv1702348662reco-desc {font-size:77%;}#yiv1702348662 .yiv1702348662replbq
{margin:4px;}#yiv1702348662 #yiv1702348662ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv1702348662 #yiv1702348662ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv1702348662
#yiv1702348662ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv1702348662
#yiv1702348662ygrp-mlmsg select, #yiv1702348662 input, #yiv1702348662 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv1702348662
#yiv1702348662ygrp-mlmsg pre, #yiv1702348662 code {font:115%
monospace;}#yiv1702348662 #yiv1702348662ygrp-mlmsg *
{line-height:1.22em;}#yiv1702348662 #yiv1702348662ygrp-mlmsg #yiv1702348662logo
{padding-bottom:10px;}#yiv1702348662 #yiv1702348662ygrp-msg p a
{font-family:Verdana;}#yiv1702348662 #yiv1702348662ygrp-msg
p#yiv1702348662attach-count span {color:#1E66AE;font-weight:700;}#yiv1702348662
#yiv1702348662ygrp-reco #yiv1702348662reco-head
{color:#ff7900;font-weight:700;}#yiv1702348662 #yiv1702348662ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv1702348662 #yiv1702348662ygrp-sponsor
#yiv1702348662ov li a {font-size:130%;text-decoration:none;}#yiv1702348662
#yiv1702348662ygrp-sponsor #yiv1702348662ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv1702348662
#yiv1702348662ygrp-sponsor #yiv1702348662ov ul {margin:0;padding:0 0 0
8px;}#yiv1702348662 #yiv1702348662ygrp-text {font-family:Georgia;}#yiv1702348662
#yiv1702348662ygrp-text p {margin:0 0 1em 0;}#yiv1702348662
#yiv1702348662ygrp-text tt {font-size:120%;}#yiv1702348662
#yiv1702348662ygrp-vital ul li:last-child {border-right:none
!important;}#yiv1702348662
Reply by "Ste...@yahoo.com [rabbit-semi]"●July 26, 20162016-07-26
I set the number of buffers equal to the number of UDP sockets. 5-sockets,
5-buffers.
I'm using one socket to send a multicast datagram twice a second to ip
224.0.100.100. Using wireshark, I only see one datagram sent. When I use
broadcast, the datagrams are constantly scrolling through the window.
I stepped through the code and it is constantly calling udp_send(), and udp_send
is returning 111, meaning it sent 111 bytes.
I enabled UDP_VERBOSE, and set debug_udp to 7. This is the output:
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
UDP: got pkt 0AFA0556:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0579:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0554:137 -> 0AFA05FF:137 payloadP
i/f=0
UDP: no applicable
socket
UDP: got pkt 0AFA0589:2099 -> FFFFFFFF:2100 payload4
i/f=0
UDP: ...using ARP table
entry
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100
payload1
The same set of print statements repeats. You can see the receipt of a broadcast
datagram sent by another piece of equipment at the 8th printout.
Each time I restart the program, wireshark shows one multicast datagram being
sent. Do you suppose this is a wireshark configuration issue, because the
Rabbit appears to be sending the packets?
I'm using an RCM3900 with DC 9.62.
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]"
To: r...
Sent: Monday, July 25, 2016 2:45 PM
Subject: Re: [rabbit-semi] Multicast
That first drop might be something to do with timing for setting up
the arp table with resolve information or something. Or, the debugger
slows things down enough for an arp to go before things get noticed.
As far as number of buffers, I think there is just a 1-to-1 correspondence
between udp sockets and udp buffers. Each socket you open in some way
needs space to stick incoming datagrams. I don't think multiple
buffers are used by the same socket. That's just a chunk of space
where an incoming datagram gets copied until you "recv" it. So,
you'll just have to make sure that you "recv" before that buffer space gets
filled up. The default is 4096 (UDP_BUF_SIZE). With 150 byte
datagrams, you can probably put a bunch in there before you start dropping
them. You might want to put some stats somewhere to track dropped packets
based on not enough space as work out your system design.
You could also use a custom datahandler on that multicast socket so you
wouldn't use the system allocated udp buffer space. I think you get
access to the ethernet packet directly that way and can do what you want with
it.
-- Dave
On 7/22/2016 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
Ah, you're right about the debug_on variable. I forgot about
that. In any case, it's working for now.
Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I was
asking about the ratio of sockets to buffers. Could I get away with a
single UDP socket and say 5 buffers without dropping datagrams?
This comes up because I am experimenting with Multicast, which I've not
used before. Normally, I open 3 sockets with REMIP and PORT set to -1, so they
will accept datagrams from any host, whether Broadcast or directed. And I have
MAX_UDP_SOCKET_BUFFERS set to 4.
To add Multicast, I needed a socket that was opened with REMIP set to a
Multicast IP. It's when I added this new socket is when the issue of losing
the first datagram appeared, and has now disappeared. When I saw the
dropped/lost first packet, I thought it might be related to the comment for
udp_extopen() in the manual that says:
"If remip is non-zero, then the process of resolving the
correct destination
hardware address is started. Datagrams cannot be sent until
sock_resolved()
returns TRUE. If you attempt to send datagrams before this,
then the
datagrams may not get sent."
But when I ran the debugger, it went away.
So now I have 4 UDP sockets, with one being for Multicast, and I increased the
buffers to 6. Should I have more Multicast sockets or less Broadcast sockets?
Could I get away with one socket of each?
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]" mailto:r...
To: r...
Sent: Friday, July 22, 2016 7:42 AM
Subject: Re: [rabbit-semi] Multicast
Along with UDP_VERBOSE, set the global debug_on to something like
7 on startup. Should produce more debug output.
And when you mention "UDP sockets" and "number of UDP buffers", are you
actually talking about some of the macros (like MAX_UDP_SOCKET_BUFFERS?)
Cuz you do need buffers to hold your packets (unless you alloc and supply your
own to the udp handler code.) I don't believe there is a limitation
to the number of udp sockets? Been a while though since I was in there. --
Dave
On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
UDP_VERBOSE doesn't do anything. There is no output when
it's defined. I'm using your updated network library, so maybe
something happened there.
In any case, after I ran my code in the debugger, it started working. So I
recompiled without debug code enabled and reloaded the program, and now it works
every time. Scary.
Slight change of subject.
First, what's the relationship between the number of UDP
sockets and number of UDP buffers? Since UDP is connectionless, a
socket for each potential device that may send a datagram is unnecessary.
But does that mean I could have one socket with a bunch of buffers? A further
explanation is, in a system we typically have 5 sub-systems, with each
sub-system sending a broadcast UDP datagram of its status twice a second. The
datagrams are around 150 bytes each. Each sub-system reads the datagrams and
collects whatever information it needs from the datagrams. So if there is only
one UDP socket and the Rabbit is processing one datagram when another one
arrives, or even two datagrams arrive, do the new datagrams get put
into unused buffers or are they lost because there is not an
unused socket available?
Steve
From: "Tom Collins t...@tomlogic.com [rabbit-semi]" mailto:r...
To: r...
Sent: Thursday, July 21, 2016 11:28 AM
Subject: Re: [rabbit-semi] Multicast
Do you see the packet come in if you define UDP_VERBOSE in your
program?
I've seen instances where the first response to a UDP datagram
doesn't go out due to needing to ARP the IP address, but there are some
ways around that (telling the stack to use the MAC from the received frame).
I'm on vacation through the end of the month, so don't have access
to code I can share, but I'm curious as to whether the datagram moves
through the TCP/IP stack at all.
-Tom
On Jul 21, 2016, at 12:23 PM, s...@yahoo.com [rabbit-semi] wrote:
I added a Multicast socket to my RCM3900 application, using IP
239.255.255.255. I have a total of 4 UDP sockets open, 3 are opened with
an REMIP and Port of -1, and one is opened with the Multicast IP and port
2100. And Max UDP Buffers is set to 5.
After boot-up, the first UDP datagram to the module is not responded to. It
doesn't matter if the datagram was a broadcast or a multicast. The first
one is not responded to. After the first one, then it starts responding to both
broadcasts and multicasts.
Is there something else I need to do to get that first datagram to work?
I'm using DC 9.62. .
#yiv8237070694 #yiv8237070694 -- #yiv8237070694ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8237070694
#yiv8237070694ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8237070694
#yiv8237070694ygrp-mkp #yiv8237070694hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8237070694 #yiv8237070694ygrp-mkp #yiv8237070694ads
{margin-bottom:10px;}#yiv8237070694 #yiv8237070694ygrp-mkp .yiv8237070694ad
{padding:0 0;}#yiv8237070694 #yiv8237070694ygrp-mkp .yiv8237070694ad p
{margin:0;}#yiv8237070694 #yiv8237070694ygrp-mkp .yiv8237070694ad a
{color:#0000ff;text-decoration:none;}#yiv8237070694 #yiv8237070694ygrp-sponsor
#yiv8237070694ygrp-lc {font-family:Arial;}#yiv8237070694
#yiv8237070694ygrp-sponsor #yiv8237070694ygrp-lc #yiv8237070694hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8237070694
#yiv8237070694ygrp-sponsor #yiv8237070694ygrp-lc .yiv8237070694ad
{margin-bottom:10px;padding:0 0;}#yiv8237070694 #yiv8237070694actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8237070694
#yiv8237070694activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8237070694
#yiv8237070694activity span {font-weight:700;}#yiv8237070694
#yiv8237070694activity span:first-child
{text-transform:uppercase;}#yiv8237070694 #yiv8237070694activity span a
{color:#5085b6;text-decoration:none;}#yiv8237070694 #yiv8237070694activity span
span {color:#ff7900;}#yiv8237070694 #yiv8237070694activity span
.yiv8237070694underline {text-decoration:underline;}#yiv8237070694
.yiv8237070694attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv8237070694 .yiv8237070694attach div a
{text-decoration:none;}#yiv8237070694 .yiv8237070694attach img
{border:none;padding-right:5px;}#yiv8237070694 .yiv8237070694attach label
{display:block;margin-bottom:5px;}#yiv8237070694 .yiv8237070694attach label a
{text-decoration:none;}#yiv8237070694 blockquote {margin:0 0 0
4px;}#yiv8237070694 .yiv8237070694bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8237070694
.yiv8237070694bold a {text-decoration:none;}#yiv8237070694 dd.yiv8237070694last
p a {font-family:Verdana;font-weight:700;}#yiv8237070694 dd.yiv8237070694last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8237070694
dd.yiv8237070694last p span.yiv8237070694yshortcuts
{margin-right:0;}#yiv8237070694 div.yiv8237070694attach-table div div a
{text-decoration:none;}#yiv8237070694 div.yiv8237070694attach-table
{width:400px;}#yiv8237070694 div.yiv8237070694file-title a, #yiv8237070694
div.yiv8237070694file-title a:active, #yiv8237070694 div.yiv8237070694file-title
a:hover, #yiv8237070694 div.yiv8237070694file-title a:visited
{text-decoration:none;}#yiv8237070694 div.yiv8237070694photo-title a,
#yiv8237070694 div.yiv8237070694photo-title a:active, #yiv8237070694
div.yiv8237070694photo-title a:hover, #yiv8237070694
div.yiv8237070694photo-title a:visited {text-decoration:none;}#yiv8237070694
div#yiv8237070694ygrp-mlmsg #yiv8237070694ygrp-msg p a
span.yiv8237070694yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8237070694
.yiv8237070694green {color:#628c2a;}#yiv8237070694 .yiv8237070694MsoNormal
{margin:0 0 0 0;}#yiv8237070694 o {font-size:0;}#yiv8237070694
#yiv8237070694photos div {float:left;width:72px;}#yiv8237070694
#yiv8237070694photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv8237070694
#yiv8237070694photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8237070694
#yiv8237070694reco-category {font-size:77%;}#yiv8237070694
#yiv8237070694reco-desc {font-size:77%;}#yiv8237070694 .yiv8237070694replbq
{margin:4px;}#yiv8237070694 #yiv8237070694ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv8237070694 #yiv8237070694ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8237070694
#yiv8237070694ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8237070694
#yiv8237070694ygrp-mlmsg select, #yiv8237070694 input, #yiv8237070694 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv8237070694
#yiv8237070694ygrp-mlmsg pre, #yiv8237070694 code {font:115%
monospace;}#yiv8237070694 #yiv8237070694ygrp-mlmsg *
{line-height:1.22em;}#yiv8237070694 #yiv8237070694ygrp-mlmsg #yiv8237070694logo
{padding-bottom:10px;}#yiv8237070694 #yiv8237070694ygrp-msg p a
{font-family:Verdana;}#yiv8237070694 #yiv8237070694ygrp-msg
p#yiv8237070694attach-count span {color:#1E66AE;font-weight:700;}#yiv8237070694
#yiv8237070694ygrp-reco #yiv8237070694reco-head
{color:#ff7900;font-weight:700;}#yiv8237070694 #yiv8237070694ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv8237070694 #yiv8237070694ygrp-sponsor
#yiv8237070694ov li a {font-size:130%;text-decoration:none;}#yiv8237070694
#yiv8237070694ygrp-sponsor #yiv8237070694ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv8237070694
#yiv8237070694ygrp-sponsor #yiv8237070694ov ul {margin:0;padding:0 0 0
8px;}#yiv8237070694 #yiv8237070694ygrp-text {font-family:Georgia;}#yiv8237070694
#yiv8237070694ygrp-text p {margin:0 0 1em 0;}#yiv8237070694
#yiv8237070694ygrp-text tt {font-size:120%;}#yiv8237070694
#yiv8237070694ygrp-vital ul li:last-child {border-right:none
!important;}#yiv8237070694
Reply by "Dav...@questcontrols.com [rabbit-semi]"●July 25, 20162016-07-25
That first drop might be something to do with timing for setting up the
arp table with resolve information or something. Or, the debugger slows
things down enough for an arp to go before things get noticed.
As far as number of buffers, I think there is just a 1-to-1
correspondence between udp sockets and udp buffers. Each socket you
open in some way needs space to stick incoming datagrams. I don't think
multiple buffers are used by the same socket. That's just a chunk of
space where an incoming datagram gets copied until you "recv" it. So,
you'll just have to make sure that you "recv" before that buffer space
gets filled up. The default is 4096 (UDP_BUF_SIZE). With 150 byte
datagrams, you can probably put a bunch in there before you start
dropping them. You might want to put some stats somewhere to track
dropped packets based on not enough space as work out your system design.
You could also use a custom datahandler on that multicast socket so you
wouldn't use the system allocated udp buffer space. I think you get
access to the ethernet packet directly that way and can do what you want
with it.
-- Dave
On 7/22/2016 9:19 AM, Steve Trigero s...@yahoo.com [rabbit-semi]
wrote: > Ah, you're right about the debug_on variable. I
forgot about that. In
> any case, it's working for now.
>
> Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I
> was asking about
> the ratio of sockets to buffers. Could I get away with a single UDP
> socket and say 5 buffers without
> dropping datagrams?
>
> This comes up because I am experimenting with Multicast, which I've
> not used before. Normally,
> I open 3 sockets with REMIP and PORT set to -1, so they will accept
> datagrams from any host,
> whether Broadcast or directed. And I have MAX_UDP_SOCKET_BUFFERS set to 4.
>
> To add Multicast, I needed a socket that was opened with REMIP set to
> a Multicast IP. It's when I
> added this new socket is when the issue of losing the first datagram
> appeared, and has now disappeared.
> When I saw the dropped/lost first packet, I thought it might be
> related to the comment for udp_extopen()
> in the manual that says:
>
> "If remip is non-zero, then the process of resolving the correct
> destination
> hardware address is started. Datagrams cannot be sent until
> sock_resolved()
> returns TRUE. If you attempt to send datagrams before this, then the
> datagrams may not get sent."
>
> But when I ran the debugger, it went away.
>
> So now I have 4 UDP sockets, with one being for Multicast, and I
> increased the buffers to 6. Should I
> have more Multicast sockets or less Broadcast sockets? Could I get
> away with one socket of each?
>
> Steve
>
>
> *From:* "Dave Moore d...@questcontrols.com [rabbit-semi]"
>
> *To:* r...
> *Sent:* Friday, July 22, 2016 7:42 AM
> *Subject:* Re: [rabbit-semi] Multicast
>
> Along with UDP_VERBOSE, set the global debug_on to something like
> 7 on startup. Should produce more debug output.
> And when you mention "UDP sockets" and "number of UDP buffers",
> are you actually talking about some of the macros (like
> MAX_UDP_SOCKET_BUFFERS?) Cuz you do need buffers to hold your
> packets (unless you alloc and supply your own to the udp handler
> code.) I don't believe there is a limitation to the number of udp
> sockets? Been a while though since I was in there.
> -- Dave
>
> On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com
> [rabbit-semi] wrote:
>> UDP_VERBOSE doesn't do anything. There is no output when
it's
>> defined. I'm using your updated network library, so maybe
>> something happened there.
>>
>> In any case, after I ran my code in the debugger, it started
>> working. So I recompiled without debug code enabled and reloaded
>> the program, and now it works every time. Scary.
>>
>> Slight change of subject.
>>
>> First, what's the relationship between the number of UDP
>> sockets and number of UDP buffers? Since UDP is connectionless, a
>> socket for each potential device that may send a datagram is
>> unnecessary. But does that mean I could have one socket with a bunch
>> of buffers? A further explanation is, in a system we typically
>> have 5 sub-systems, with each sub-system sending a broadcast UDP
>> datagram of its status twice a second. The datagrams are around
>> 150 bytes each. Each sub-system reads the datagrams and collects
>> whatever information it needs from the datagrams. So if there is
>> only one UDP socket and the Rabbit is processing one datagram
>> when another one arrives, or even two datagrams arrive, do the
>> new datagrams get put into unused buffers or are they lost because
>> there is not an unused socket available?
>>
>> Steve
>>
>>
>> *From:* "Tom Collins t...@tomlogic.com
>> [rabbit-semi]"
>> mailto:r...
>> *To:* r...
>>
>> *Sent:* Thursday, July 21, 2016 11:28 AM
>> *Subject:* Re: [rabbit-semi] Multicast
>>
>> Do you see the packet come in if you define UDP_VERBOSE in
>> your program?
>>
>> I've seen instances where the first response to a UDP
>> datagram doesn't go out due to needing to ARP the IP address,
>> but there are some ways around that (telling the stack to use
>> the MAC from the received frame).
>>
>> I'm on vacation through the end of the month, so don't
have
>> access to code I can share, but I'm curious as to whether the
>> datagram moves through the TCP/IP stack at all.
>>
>> -Tom
>> On Jul 21, 2016, at 12:23 PM, s...@yahoo.com
>> [rabbit-semi] wrote:
>>>
>>> I added a Multicast socket to my RCM3900 application, using
>>> IP 239.255.255.255. I have a total of 4 UDP sockets open, 3
>>> are opened with an REMIP and Port of -1, and one is opened
>>> with the Multicast IP and port 2100. And Max UDP Buffers is
>>> set to 5.
>>>
>>> After boot-up, the first UDP datagram to the module is not
>>> responded to. It doesn't matter if the datagram was a
>>> broadcast or a multicast. The first one is not responded to.
>>> After the first one, then it starts responding to both
>>> broadcasts and multicasts.
>>>
>>> Is there something else I need to do to get that first
>>> datagram to work?
>>>
>>> I'm using DC 9.62.
>>> .
>
Reply by "Ste...@yahoo.com [rabbit-semi]"●July 22, 20162016-07-22
Ah, you're right about the debug_on variable. I forgot about that. In any
case, it's working for now.
Yes, I was referring to MAX_UDP_SOCKET_BUFFERS. I know I need them. I was asking
about the ratio of sockets to buffers. Could I get away with a single UDP
socket and say 5 buffers withoutdropping datagrams?
This comes up because I am experimenting with Multicast, which I've not
used before. Normally,I open 3 sockets with REMIP and PORT set to -1, so they
will accept datagrams from any host,whether Broadcast or directed. And I have
MAX_UDP_SOCKET_BUFFERS set to 4.
To add Multicast, I needed a socket that was opened with REMIP set to a
Multicast IP. It's when Iadded this new socket is when the issue of losing
the first datagram appeared, and has now disappeared. When I saw the
dropped/lost first packet, I thought it might be related to the comment for
udp_extopen() in the manual that says:
"If remip is non-zero, then the process of resolving the
correct destination
hardware address is started. Datagrams cannot be sent until
sock_resolved()
returns TRUE. If you attempt to send datagrams before this,
then the
datagrams may not get sent."
But when I ran the debugger, it went away.
So now I have 4 UDP sockets, with one being for Multicast, and I increased the
buffers to 6. Should Ihave more Multicast sockets or less Broadcast sockets?
Could I get away with one socket of each?
Steve
From: "Dave Moore d...@questcontrols.com [rabbit-semi]"
To: r...
Sent: Friday, July 22, 2016 7:42 AM
Subject: Re: [rabbit-semi] Multicast
Along with UDP_VERBOSE, set the global debug_on to something like 7 on
startup. Should produce more debug output.
And when you mention "UDP sockets" and "number of UDP buffers", are you
actually talking about some of the macros (like MAX_UDP_SOCKET_BUFFERS?)
Cuz you do need buffers to hold your packets (unless you alloc and supply your
own to the udp handler code.) I don't believe there is a limitation
to the number of udp sockets? Been a while though since I was in there. --
Dave
On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com [rabbit-semi] wrote:
UDP_VERBOSE doesn't do anything. There is no output when
it's defined. I'm using your updated network library, so maybe
something happened there.
In any case, after I ran my code in the debugger, it started working. So I
recompiled without debug code enabled and reloaded the program, and now it works
every time. Scary.
Slight change of subject.
First, what's the relationship between the number of UDP
sockets and number of UDP buffers? Since UDP is connectionless, a
socket for each potential device that may send a datagram is unnecessary.
But does that mean I could have one socket with a bunch of buffers? A further
explanation is, in a system we typically have 5 sub-systems, with each
sub-system sending a broadcast UDP datagram of its status twice a second. The
datagrams are around 150 bytes each. Each sub-system reads the datagrams and
collects whatever information it needs from the datagrams. So if there is only
one UDP socket and the Rabbit is processing one datagram when another one
arrives, or even two datagrams arrive, do the new datagrams get put
into unused buffers or are they lost because there is not an
unused socket available?
Steve
From: "Tom Collins t...@tomlogic.com [rabbit-semi]" mailto:r...
To: r...
Sent: Thursday, July 21, 2016 11:28 AM
Subject: Re: [rabbit-semi] Multicast
Do you see the packet come in if you define UDP_VERBOSE in your
program?
I've seen instances where the first response to a UDP datagram
doesn't go out due to needing to ARP the IP address, but there are some
ways around that (telling the stack to use the MAC from the received frame).
I'm on vacation through the end of the month, so don't have access
to code I can share, but I'm curious as to whether the datagram moves
through the TCP/IP stack at all.
-Tom
On Jul 21, 2016, at 12:23 PM, s...@yahoo.com [rabbit-semi] wrote:
I added a Multicast socket to my RCM3900 application, using IP
239.255.255.255. I have a total of 4 UDP sockets open, 3 are opened with
an REMIP and Port of -1, and one is opened with the Multicast IP and port 2100.
And Max UDP Buffers is set to 5.
After boot-up, the first UDP datagram to the module is not responded to. It
doesn't matter if the datagram was a broadcast or a multicast. The first
one is not responded to. After the first one, then it starts responding to both
broadcasts and multicasts.
Is there something else I need to do to get that first datagram to work?
I'm using DC 9.62. .
#yiv3715481391 #yiv3715481391 -- #yiv3715481391ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3715481391
#yiv3715481391ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3715481391
#yiv3715481391ygrp-mkp #yiv3715481391hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3715481391 #yiv3715481391ygrp-mkp #yiv3715481391ads
{margin-bottom:10px;}#yiv3715481391 #yiv3715481391ygrp-mkp .yiv3715481391ad
{padding:0 0;}#yiv3715481391 #yiv3715481391ygrp-mkp .yiv3715481391ad p
{margin:0;}#yiv3715481391 #yiv3715481391ygrp-mkp .yiv3715481391ad a
{color:#0000ff;text-decoration:none;}#yiv3715481391 #yiv3715481391ygrp-sponsor
#yiv3715481391ygrp-lc {font-family:Arial;}#yiv3715481391
#yiv3715481391ygrp-sponsor #yiv3715481391ygrp-lc #yiv3715481391hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3715481391
#yiv3715481391ygrp-sponsor #yiv3715481391ygrp-lc .yiv3715481391ad
{margin-bottom:10px;padding:0 0;}#yiv3715481391 #yiv3715481391actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3715481391
#yiv3715481391activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3715481391
#yiv3715481391activity span {font-weight:700;}#yiv3715481391
#yiv3715481391activity span:first-child
{text-transform:uppercase;}#yiv3715481391 #yiv3715481391activity span a
{color:#5085b6;text-decoration:none;}#yiv3715481391 #yiv3715481391activity span
span {color:#ff7900;}#yiv3715481391 #yiv3715481391activity span
.yiv3715481391underline {text-decoration:underline;}#yiv3715481391
.yiv3715481391attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3715481391 .yiv3715481391attach div a
{text-decoration:none;}#yiv3715481391 .yiv3715481391attach img
{border:none;padding-right:5px;}#yiv3715481391 .yiv3715481391attach label
{display:block;margin-bottom:5px;}#yiv3715481391 .yiv3715481391attach label a
{text-decoration:none;}#yiv3715481391 blockquote {margin:0 0 0
4px;}#yiv3715481391 .yiv3715481391bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3715481391
.yiv3715481391bold a {text-decoration:none;}#yiv3715481391 dd.yiv3715481391last
p a {font-family:Verdana;font-weight:700;}#yiv3715481391 dd.yiv3715481391last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3715481391
dd.yiv3715481391last p span.yiv3715481391yshortcuts
{margin-right:0;}#yiv3715481391 div.yiv3715481391attach-table div div a
{text-decoration:none;}#yiv3715481391 div.yiv3715481391attach-table
{width:400px;}#yiv3715481391 div.yiv3715481391file-title a, #yiv3715481391
div.yiv3715481391file-title a:active, #yiv3715481391 div.yiv3715481391file-title
a:hover, #yiv3715481391 div.yiv3715481391file-title a:visited
{text-decoration:none;}#yiv3715481391 div.yiv3715481391photo-title a,
#yiv3715481391 div.yiv3715481391photo-title a:active, #yiv3715481391
div.yiv3715481391photo-title a:hover, #yiv3715481391
div.yiv3715481391photo-title a:visited {text-decoration:none;}#yiv3715481391
div#yiv3715481391ygrp-mlmsg #yiv3715481391ygrp-msg p a
span.yiv3715481391yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3715481391
.yiv3715481391green {color:#628c2a;}#yiv3715481391 .yiv3715481391MsoNormal
{margin:0 0 0 0;}#yiv3715481391 o {font-size:0;}#yiv3715481391
#yiv3715481391photos div {float:left;width:72px;}#yiv3715481391
#yiv3715481391photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv3715481391
#yiv3715481391photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3715481391
#yiv3715481391reco-category {font-size:77%;}#yiv3715481391
#yiv3715481391reco-desc {font-size:77%;}#yiv3715481391 .yiv3715481391replbq
{margin:4px;}#yiv3715481391 #yiv3715481391ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv3715481391 #yiv3715481391ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3715481391
#yiv3715481391ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3715481391
#yiv3715481391ygrp-mlmsg select, #yiv3715481391 input, #yiv3715481391 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv3715481391
#yiv3715481391ygrp-mlmsg pre, #yiv3715481391 code {font:115%
monospace;}#yiv3715481391 #yiv3715481391ygrp-mlmsg *
{line-height:1.22em;}#yiv3715481391 #yiv3715481391ygrp-mlmsg #yiv3715481391logo
{padding-bottom:10px;}#yiv3715481391 #yiv3715481391ygrp-msg p a
{font-family:Verdana;}#yiv3715481391 #yiv3715481391ygrp-msg
p#yiv3715481391attach-count span {color:#1E66AE;font-weight:700;}#yiv3715481391
#yiv3715481391ygrp-reco #yiv3715481391reco-head
{color:#ff7900;font-weight:700;}#yiv3715481391 #yiv3715481391ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv3715481391 #yiv3715481391ygrp-sponsor
#yiv3715481391ov li a {font-size:130%;text-decoration:none;}#yiv3715481391
#yiv3715481391ygrp-sponsor #yiv3715481391ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv3715481391
#yiv3715481391ygrp-sponsor #yiv3715481391ov ul {margin:0;padding:0 0 0
8px;}#yiv3715481391 #yiv3715481391ygrp-text {font-family:Georgia;}#yiv3715481391
#yiv3715481391ygrp-text p {margin:0 0 1em 0;}#yiv3715481391
#yiv3715481391ygrp-text tt {font-size:120%;}#yiv3715481391
#yiv3715481391ygrp-vital ul li:last-child {border-right:none
!important;}#yiv3715481391
Reply by "Dav...@questcontrols.com [rabbit-semi]"●July 22, 20162016-07-22
Along with UDP_VERBOSE, set the global debug_on to something like 7 on
startup. Should produce more debug output.
And when you mention "UDP sockets" and "number of UDP buffers", are you
actually talking about some of the macros (like
MAX_UDP_SOCKET_BUFFERS?) Cuz you do need buffers to hold your packets
(unless you alloc and supply your own to the udp handler code.) I don't
believe there is a limitation to the number of udp sockets? Been a
while though since I was in there.
-- Dave
On 7/21/2016 2:55 PM, Steve Trigero s...@yahoo.com [rabbit-semi]
wrote: > UDP_VERBOSE doesn't do anything. There is no
output when it's defined.
> I'm using your updated network library, so maybe
> something happened there.
>
> In any case, after I ran my code in the debugger, it started working.
> So I recompiled without debug code enabled and reloaded
> the program, and now it works every time. Scary.
>
> Slight change of subject.
>
> First, what's the relationship between the number of UDP sockets and
> number of UDP buffers? Since UDP is connectionless, a
> socket for each potential device that may send a datagram is
> unnecessary. But does that mean I could have one socket with a bunch
> of buffers? A further explanation is, in a system we typically have 5
> sub-systems, with each sub-system sending a broadcast UDP
> datagram of its status twice a second. The datagrams are around 150
> bytes each. Each sub-system reads the datagrams and collects
> whatever information it needs from the datagrams. So if there is only
> one UDP socket and the Rabbit is processing one datagram
> when another one arrives, or even two datagrams arrive, do the new
> datagrams get put into unused buffers or are they lost because
> there is not an unused socket available?
>
> Steve
>
>
> *From:* "Tom Collins t...@tomlogic.com [rabbit-semi]"
>
> *To:* r...
> *Sent:* Thursday, July 21, 2016 11:28 AM
> *Subject:* Re: [rabbit-semi] Multicast
>
> Do you see the packet come in if you define UDP_VERBOSE in your
> program?
>
> I've seen instances where the first response to a UDP datagram
> doesn't go out due to needing to ARP the IP address, but there are
> some ways around that (telling the stack to use the MAC from the
> received frame).
>
> I'm on vacation through the end of the month, so don't have
access
> to code I can share, but I'm curious as to whether the datagram
> moves through the TCP/IP stack at all.
>
> -Tom
> On Jul 21, 2016, at 12:23 PM, s...@yahoo.com
> [rabbit-semi] wrote:
>>
>> I added a Multicast socket to my RCM3900 application, using IP
>> 239.255.255.255. I have a total of 4 UDP sockets open, 3 are
>> opened with an REMIP and Port of -1, and one is opened with the
>> Multicast IP and port 2100. And Max UDP Buffers is set to 5.
>>
>> After boot-up, the first UDP datagram to the module is not
>> responded to. It doesn't matter if the datagram was a broadcast
>> or a multicast. The first one is not responded to. After the
>> first one, then it starts responding to both broadcasts and
>> multicasts.
>>
>> Is there something else I need to do to get that first datagram
>> to work?
>>
>> I'm using DC 9.62.
>> .
Reply by "'Ma...@cemitonline.com [rabbit-semi]"●July 22, 20162016-07-22
I've noticed the same issue. My application (run on a RCM3900,
compiled with DC 9.62) send UDP message events to a server. The
first one (and only that one) is lost, then everything goes well. I
never understood why.
Il 21/07/2016 23:55, Steve Trigero s...@yahoo.com [rabbit-semi] ha scritto:
cite="mid:8...@mail.yahoo.com"
type="cite">
style="color:#000;background-color:#fff;font-family:times
new roman, new york, times, serif;font-size:16px;">
id="yui_3_16_0_ym19_1_1469108232123_7900">UDP_VERBOSE
doesn't do anything. There is no output when it's
defined. I'm using your updated network library, so
maybe
id="yui_3_16_0_ym19_1_1469108232123_7639">In any case,
after I ran my code in the debugger, it started
working. So I recompiled without debug code enabled
and reloaded
id="yui_3_16_0_ym19_1_1469108232123_7772">the program,
and now it works every time. Scary.
id="yui_3_16_0_ym19_1_1469108232123_7598">
id="yui_3_16_0_ym19_1_1469108232123_7700" dir="ltr">Slight
change of subject.
id="yui_3_16_0_ym19_1_1469108232123_7778" dir="ltr">
id="yui_3_16_0_ym19_1_1469108232123_7779" dir="ltr">First,
what's the relationship between the number
of UDP
sockets and number of UDP buffers? Since UDP is
connectionless, a
id="yui_3_16_0_ym19_1_1469108232123_7890" dir="ltr">socket
for each potential device that may send a datagram is
unnecessary. But does that mean I could have one socket
with a bunch
id="yui_3_16_0_ym19_1_1469108232123_7891" dir="ltr">of
buffers? A further explanation is, in a system we
typically have 5 sub-systems, with each sub-system
sending a broadcast UDP
id="yui_3_16_0_ym19_1_1469108232123_7903" dir="ltr">datagram
of its status twice a second. The datagrams are around
150 bytes each. Each sub-system reads the datagrams and
collects
id="yui_3_16_0_ym19_1_1469108232123_7892" dir="ltr">whatever
information it needs from the datagrams. So if there is
only one UDP socket and the Rabbit is processing one
datagram
id="yui_3_16_0_ym19_1_1469108232123_7893" dir="ltr">when
another one arrives, or even two datagrams arrive, do
the new datagrams get put into unused buffers or
are
they lost because
id="yui_3_16_0_ym19_1_1469108232123_7904" dir="ltr">there
is not an unused socket available?
id="yui_3_16_0_ym19_1_1469108232123_7905" dir="ltr">