[prev in list] [next in list] [prev in thread] [next in thread]
List: spread-users
Subject: RE: [Spread-users] Spread daemon -8 and -11 errors
From: "Chetan Gadgil" <cgadgil_list () cxoindia ! dnsalias ! com>
Date: 2003-12-25 4:54:40
[Download RAW message or body]
> > 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
>
_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic