Multicast

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. Start a New Thread

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.
>
> .
> Start a New Thread

UDP_VERBOSE doesn't do anything. There is no output when it's defined. I'm using your updated network library, so maybesomething happened there.
In any case, after I ran my code in the debugger, it started working. So I recompiled without debug code enabled and reloadedthe 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..

#yiv2014001201 #yiv2014001201 -- #yiv2014001201ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2014001201 #yiv2014001201ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2014001201 #yiv2014001201ygrp-mkp #yiv2014001201hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv2014001201 #yiv2014001201ygrp-mkp #yiv2014001201ads {margin-bottom:10px;}#yiv2014001201 #yiv2014001201ygrp-mkp .yiv2014001201ad {padding:0 0;}#yiv2014001201 #yiv2014001201ygrp-mkp .yiv2014001201ad p {margin:0;}#yiv2014001201 #yiv2014001201ygrp-mkp .yiv2014001201ad a {color:#0000ff;text-decoration:none;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ygrp-lc {font-family:Arial;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ygrp-lc #yiv2014001201hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ygrp-lc .yiv2014001201ad {margin-bottom:10px;padding:0 0;}#yiv2014001201 #yiv2014001201actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2014001201 #yiv2014001201activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2014001201 #yiv2014001201activity span {font-weight:700;}#yiv2014001201 #yiv2014001201activity span:first-child {text-transform:uppercase;}#yiv2014001201 #yiv2014001201activity span a {color:#5085b6;text-decoration:none;}#yiv2014001201 #yiv2014001201activity span span {color:#ff7900;}#yiv2014001201 #yiv2014001201activity span .yiv2014001201underline {text-decoration:underline;}#yiv2014001201 .yiv2014001201attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv2014001201 .yiv2014001201attach div a {text-decoration:none;}#yiv2014001201 .yiv2014001201attach img {border:none;padding-right:5px;}#yiv2014001201 .yiv2014001201attach label {display:block;margin-bottom:5px;}#yiv2014001201 .yiv2014001201attach label a {text-decoration:none;}#yiv2014001201 blockquote {margin:0 0 0 4px;}#yiv2014001201 .yiv2014001201bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv2014001201 .yiv2014001201bold a {text-decoration:none;}#yiv2014001201 dd.yiv2014001201last p a {font-family:Verdana;font-weight:700;}#yiv2014001201 dd.yiv2014001201last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2014001201 dd.yiv2014001201last p span.yiv2014001201yshortcuts {margin-right:0;}#yiv2014001201 div.yiv2014001201attach-table div div a {text-decoration:none;}#yiv2014001201 div.yiv2014001201attach-table {width:400px;}#yiv2014001201 div.yiv2014001201file-title a, #yiv2014001201 div.yiv2014001201file-title a:active, #yiv2014001201 div.yiv2014001201file-title a:hover, #yiv2014001201 div.yiv2014001201file-title a:visited {text-decoration:none;}#yiv2014001201 div.yiv2014001201photo-title a, #yiv2014001201 div.yiv2014001201photo-title a:active, #yiv2014001201 div.yiv2014001201photo-title a:hover, #yiv2014001201 div.yiv2014001201photo-title a:visited {text-decoration:none;}#yiv2014001201 div#yiv2014001201ygrp-mlmsg #yiv2014001201ygrp-msg p a span.yiv2014001201yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv2014001201 .yiv2014001201green {color:#628c2a;}#yiv2014001201 .yiv2014001201MsoNormal {margin:0 0 0 0;}#yiv2014001201 o {font-size:0;}#yiv2014001201 #yiv2014001201photos div {float:left;width:72px;}#yiv2014001201 #yiv2014001201photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv2014001201 #yiv2014001201photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv2014001201 #yiv2014001201reco-category {font-size:77%;}#yiv2014001201 #yiv2014001201reco-desc {font-size:77%;}#yiv2014001201 .yiv2014001201replbq {margin:4px;}#yiv2014001201 #yiv2014001201ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv2014001201 #yiv2014001201ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv2014001201 #yiv2014001201ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv2014001201 #yiv2014001201ygrp-mlmsg select, #yiv2014001201 input, #yiv2014001201 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv2014001201 #yiv2014001201ygrp-mlmsg pre, #yiv2014001201 code {font:115% monospace;}#yiv2014001201 #yiv2014001201ygrp-mlmsg * {line-height:1.22em;}#yiv2014001201 #yiv2014001201ygrp-mlmsg #yiv2014001201logo {padding-bottom:10px;}#yiv2014001201 #yiv2014001201ygrp-msg p a {font-family:Verdana;}#yiv2014001201 #yiv2014001201ygrp-msg p#yiv2014001201attach-count span {color:#1E66AE;font-weight:700;}#yiv2014001201 #yiv2014001201ygrp-reco #yiv2014001201reco-head {color:#ff7900;font-weight:700;}#yiv2014001201 #yiv2014001201ygrp-reco {margin-bottom:20px;padding:0px;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ov li a {font-size:130%;text-decoration:none;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv2014001201 #yiv2014001201ygrp-sponsor #yiv2014001201ov ul {margin:0;padding:0 0 0 8px;}#yiv2014001201 #yiv2014001201ygrp-text {font-family:Georgia;}#yiv2014001201 #yiv2014001201ygrp-text p {margin:0 0 1em 0;}#yiv2014001201 #yiv2014001201ygrp-text tt {font-size:120%;}#yiv2014001201 #yiv2014001201ygrp-vital ul li:last-child {border-right:none !important;}#yiv2014001201 Start a New Thread

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.

cite="mid:8...@mail.yahoo.com"
type="cite">  


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">


id="yui_3_16_0_ym19_1_1469108232123_7906" dir="ltr">Steve









Marco Rossi









__._,_.___




























__,_._,___
Start a New Thread

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.
>> . Start a New Thread

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 Start a New Thread

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.
>>> .
> Start a New Thread

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 Start a New Thread

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 Start a New Thread

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 Start a New Thread