Re: 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 seecwriter-/[email protected] [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 dmoore-f4pv2F5LI2c/CDIEhCN/twC/[email protected] [rabbit-semi]"
>     <[email protected]>
>     *To:* [email protected]
>     *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 seecwriter-/[email protected]
>     <mailto:seecwriter-/[email protected]> [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 tom-lnEA/wrDJtNWk0Htik3J/[email protected]
>>         <mailto:tom-lnEA/wrDJtNWk0Htik3J/[email protected]> [rabbit-semi]"
>>         mailto:[email protected]
>>         *To:* [email protected]
>>         <mailto:[email protected]>
>>         *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, seecwriter-/[email protected]
>>         <mailto:seecwriter-/[email protected]> [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.
>>>         .
>>
>>
>>
>
>
>