[Spread-users] lost flooder messages

Yair Amir yairamir at cnds.jhu.edu
Fri May 9 19:01:42 EDT 2003

Ok, so a different client - not spflooder but a regular spuser does
not receive all the messages. This should not happen.
Do you let that spuser stay up for a while and it still does
not receive the messages?
(if a client does not keep up, spread is buffering up to 1000 messages
for it, but then will try to send to it only in a few second)
so just to make sure:

1. you send 10000 messages by your modified spflooder
2. the spuser that joins the "flooder" group ahead of time
   only receives the first 9994 messages even if you leave it running
   for a while after spflooder exited.

   Is this correct?
   Also, try to send a message to "flooder" group by spuser after
   the modified spflooder exited  and see if you get that message.

   Also, I am not sure in which program you added a "sleep" that
   bypassed the problem.

   Also, specify exactly how you connected with Spread (IPC or TCP)
   and wether locally or remotely for any client that connected to
   spread in this experiment. Also, how many daemons you have in the
   system and which client connects to which daemon.

   :) Yair.
On Friday, May 09, 2003 4:56 PM
Kelvin Fedrick Kelvin.Fedrick at noaa.gov wrote:

Kelvin> Yair Amir wrote:

>> Hi Kelvin,
>> I just look at the flooder program and see that it is
>> not designed to wait until it receives all of the messages it sent
>> in the case where the flooder sends AND receives at the same time.
>> It could be modified to do that though.
>> From a quick scan of the current code I see that in such a case the first 200
>> messages are sent without receiving any messages and after that every
>> message sent is followed by at least one message received, exactly one
>> which is sent by the same flooder.
>> So it is very possible that the last few messages will not be received
>> before flooder exits. I did not look at this code for a while.
>> Somehow I vaguely recall that when written, flooder was designed to receive
>> all the messages it sent (but this portion of the code seems missing in
>> the current version 3.17.0).
>> In general, flooder is not a program that aims to demonstrate that
>> Spread does not lose messages - just to benchmark its performance.
>> Let us know what you are trying to do so that we can understand
>> how best to help.
>>      Cheers,
>>      :) Yair.

Kelvin> Hi Yair,

Kelvin>    First let me clarify the situation. We used flooder to send the messages but
Kelvin> we used a seperate client, the spuser, to receive the messages - sometimes a
Kelvin> couple of them. The spuser is where we've observed the message loss, not
Kelvin> in the flooder.

Kelvin>    All I'm trying to do is understand why the messages spflooder sent weren't
Kelvin> delivered to the spuser client and what to do to insure that they are delivered.
Kelvin> If we need to write our processes to delay before exiting after using SP_multicast
Kelvin> to send a message, that's fine but I just need to know that so we can design around
Kelvin> it. As John has suggested, it does sound as if the TCP/IP buffer may be dropping the
Kelvin> message when spflooder disconnects.

Kelvin>    As for the modification, all I did was add the following line before the SP_multicast
Kelvin> call so as I can see the message number as the receiver gets it.

Kelvin>       sprintf(mess, "%d AAAA", i);

Kelvin> Thanks.

Kelvin> Kelvin

More information about the Spread-users mailing list