[Spread-users] Spread daemon -8 and -11 errors

[Chetan Gadgil]

> > should kill the sender.
> 
> Chetan,
> 
> That would mean that in a stable network of 5 nodes sending "fast" 
> group communication traffic, someone only needs to connect 
> and not read 
> to bring the whole conversation to a halt -- it would be a 
> slow reader 
> and cause everyone else to slow down.
> 
> Instead, disconnecting the slow receiver while still maintaining the 
> group membership semantics of message delivery is a viable and more 
> reasonable approach.


Hmm, good point.


> 
> Basically, the flow control you speak of can be built in the 
> application level on top of what exists.  But, what exists now could 
> never be built on top of the framework you suggest.
> 
> Open groups complicate things as the publishers are not necessarily 
> participating the in receiving group and may not be privy to the 
> delivery of sent messages.  In closed groups you can 
> implement the flow 
> control you desire and if you require open semantics, you simple need 
> to utilize on closed "control group" to implement flow control in an 
> open group as Spread enforces its delivery semantics _across_ groups.
> 
> I will not argue that this task may be too intimidating for a 
> new user 
> to accomplish and it is reasonable to need such a framework.  
> Also, it 
> has likely been built n times by n different parties.  I suggest an 
> initiative to build a generic, intuitive flow control library 
> built on 
> top of lib(t)spread that provides these semantics.
> 
> What does everyone thing about that?


I have been trying to use the Spread client libraries from within .NET.

I tried using the contributed C# library but ran into some stability
problems. Hence, I wrote a 16 line layer using .NET Pinvoke. This is not
necessarily the most efficient approach (for performance), however, I
doubt that the performance will be much better using a managed wrapper.

I wanted to avoid getting to the native level as I need to build
something (that uses messaging) on top, at the application level.

Regards
Chetan Gadgil
Product Architect
CXO Systems Inc.
http://www.cxosystems.com



> 
> // Theo Schlossnagle
> // Principal Engineer -- http://www.omniti.com/~jesus/
> // Postal Engine -- http://www.postalengine.com/
> // Ecelerity: fastest MTA on earth
>