[Spread-users] Spread and reliable message communication

John Schultz jschultz at commedia.cnds.jhu.edu
Fri Aug 8 15:44:02 EDT 2003


One other thing to consider is that if your sender immediately exits after
sending its messages, then some of the data might not even make it to
the Spread daemon.  I think this happens because of IPC or TCP/IP
buffering: when your app dies data in the buffers is often lost.

So make sure your sender doesn't just immediately quit.

John Schultz
Co-Founder, Lead Engineer
D-Fusion, Inc. (http://www.d-fusion.net)
Phn: 443 838 2200

On Fri, 8 Aug 2003, Ryan Caudy wrote:

> Spread does not block the sender for sending too fast, as long as there
> is room in Spread's internal buffers to hold the incoming (at which
> point it will block the application by not receiving from the socket at
> its end).  Spread's response to a "slow" receiver is to cut the receiver
> off.  This forces flow control to be done by the client.  So, likely
> what you're seeing is the client being cut off for being too slow... you
> can confirm this by examining the return code given to the SP_receive
> call that returns an error.
>
> --Ryan
>
> Tuvi, Selim wrote:
>
> > Hi, we just started experimenting with the Python extension module for Spread and we are having problems in reliably sending and receiving messages. We tested this only under a Windows XP environment and only under Python so bear with us. I e-mailed the same question to Guido van Rossum, maintainer of the Python extension and he seems to think the problem has nothing to do with the Python wrappers.
> >
> > The attached files demonstrate the problem. We read a file that contains chunks of binary data about 800 bytes in size. In a loop we send the contents (the file contains 5 chunks) 1000 times to the receiver. If the CPU is loaded 100% then after a while the receiving side stops receiving the data. It doesn't seem to drop packets since I am also sending the message number as a value in the msg_type member and the last msg_type value matches the received number of messages.
> >
> > We observed that The sending process finishes to completion and reports that 4072000 bytes were sent. The receiving process on the other hand stops after about 600-800 packets depending on the load. I deliberatly slowed down the receiving side by dumping the contents of the received messages.
> >
> > As far as I could read from the documentation, if the sender is sending faster than the receiving side can process, then the sender should block, but this is not the case. We don't observe any blocking on the sender at all. We tried using FIFO_MESS or RELIABLE_MESS as the service type but that doesn't seem to make any difference.
> >
> > If you can shed some light on this problem or if we didn't understand the Spread concepts fully we appreciate it if you can steer us in the right direction.
> >
> > Testing was done under a Windows XP machine with ActiveState Python 2.2.2 build 224. Spread extension version is 1.3 and Spread version is version 3.17.01 built on 20/June/2003.
> >
> > Thanks
> > -Selim
> >
> > Selim Tuvi, Research Engineering Group, SLAC
> > GLAST, I&T Online, MS 98
> > Tel:650-926-3376 Fax:650-926-4335
> >
> >
>
> --
> Ryan W. Caudy
> Center for Networking and Distributed Systems
> Department of Computer Science
> Johns Hopkins University
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>





More information about the Spread-users mailing list