[Spread-users] Why is SP_scat_receive() returning -1 ?

John Lane Schultz jschultz at spreadconcepts.com
Mon Aug 6 11:42:11 EDT 2007

Sorry, I didn't see your message earlier.

Vipul Shinde wrote:
> Hi,
> I am a new to Spread.
> Also I would like to know a couple of things :
> 1. Type of communication protocol is used between daemons
> 2. Type of communication protocol is used daemon  and client.

1. It is a custom UDP protocol.
2. Either TCP/IP or IPC (unix pipes) depending on how you connect to the daemon.

> Also I  have  seen   a "abcd"  file of type socket is been created in 
> /tmp/ when we start daemon. (abcd = port number configured)
> Is that the client and daemon use this file for interprocess  
> communication  ?  How do they  communicate  ?

I'm not 100% sure, but I believe this is the named pipe through which clients 
using IPC connect to the daemon.

> Also I am facing a situation in which recv() returns -1 in below code 
> snippet in function *SP_scat_receive() *
> while(((ret = recv( mbox, &buf_ptr[len], remain, 0 )) == -1 )
>                               && ((sock_errno == EINTR) || (sock_errno 
> == EAGAIN) || (sock_errno == EWOULDBLOCK)) )
>  if( ret <=0 )
>                         {
>                                 Mutex_unlock( &Mbox_mutex[mbox & 
>                                 SP_kill( mbox );
>                                 return( CONNECTION_CLOSED );
>                         }
> Is that the client is not able to receive messages from the daemon ?
> What can be reason for recv() returning -1 ?

Your connection to the daemon is failing.  This can happen for many reasons, but 
the most common reason when using Spread is that the daemon purposely killed 
your client connection because it was reading messages too slowly.

If you have senders in your system that are sending quite fast, then you need to 
implement some form of flow control such that your senders can't outrun your 
receivers by too much.  If you don't do that, then the messages for your 
receivers begin piling up in the daemon eating its memory resources. 
Eventually, if the condition persists the daemon would crash due to memory 
exhaustion.  Instead of having the daemon fail and killing all its client 
connections, if the daemon sees your client falling persistently behind it will 
eventually disconnect that particular receiver.


John Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875

More information about the Spread-users mailing list