Re: 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 payload=111                     
UDP: got pkt 0AFA0556:137 -> 0AFA05FF:137 payload=50 i/f=0                      
UDP: no applicable socket                                                       
UDP: got pkt 0AFA0579:137 -> 0AFA05FF:137 payload=50 i/f=0                      
UDP: no applicable socket                                                       
UDP: got pkt 0AFA0554:137 -> 0AFA05FF:137 payload=50 i/f=0                      
UDP: no applicable socket                                                       
UDP: got pkt 0AFA0589:2099 -> FFFFFFFF:2100 payload=104 i/f=0                   
UDP: ...using ARP table entry                                                   
UDP: sending pkt 0AFA0582:2100 -> E0006464:2100 payload=111                     

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 dmoore-f4pv2F5LI2c/CDIEhCN/twC/[email protected] [rabbit-semi]" <[email protected]>
 To: [email protected] 
 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 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]" mailto:[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] [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] [rabbit-semi]" mailto:[email protected]
 To: [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] [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