Talk:Virtual synchrony

message: In the talk page below, there are (seemingly) years of complaints about this page, and despite the claim of one person that the article was written by one person, it shows obvious signs of the too many authors problem common to Wikipedia articles that have been edited in haphazard ways by many people.  I did some work on it during a break in the SOCC conference in Seattle, but I can see now that what this really needs is a complete rewrite by Yair Amir (Spread), Ken Birman (Isis2) or some other person who writes well and knows the model well.  The current revision isn't really very satisfactory.
: Just noticed this.  First, thanks for jumping in and just fixing the language.  But let me ask a question.  One group of people are complaining that people like Yair and me would be biased and shouldn't touch the page.  Now here you go saying Yair or I should revise the page "heavily".  Which group is right?
: I had understood that Wikipedia really centers on unbiased editors.  So if the technical content is correct, my feeling is that I should stay disengaged.  At a glance the page can definitely be improved at this point (your comment about too many authors seems about right to me).  So one person doing a top-to-bottom rewrite would certainly help.  But if that person was me, wouldn't that just double down on the biased editor concerns?
: Seriously, I'll do what I should to help.  But I need to understand: what am I supposed to do, under Wikipedia policy? Ken Birman (talk) 12:58, 10 November 2014 (UTC)
thread_title:  Heavy revision needed 

message: The references currently in the article are as follows, but of course I'm a co-author on a few of them.  Just to head off any kind of flaming, I don't have anything to sell, not even the book -- I did write it, but I don't get a penny of royalties on this book.  Springer has a deal under which they will cut the price of a book quite deeply if the author declines royalties, and a book like this never makes much money anyhow, so I took the deal.  And indeed, the book is cheaper as a result.
* Reliable Distributed Systems: Technologies, Web Services and Applications.  K.P. Birman.  Springer Verlag (1997).  Book, covers all of the replication technologies in question.
* Distributed Systems: Principles and Paradigms (2nd Edition).  Andrew S. Tanenbaum, Maarten van Steen (2002).   Book, famous authors; also covers all of the replication technologies in question.
* "The process group approach to reliable distributed computing".  K.P. Birman, Communications of the ACM (CACM) 16:12 (Dec. 1993).  Easiest single article to read, for general audiences.
* "Group communication specifications: a comprehensive study"   Gregory V. Chockler, Idit Keidar, Roman Vitenberg.  ACM Computing Surveys 33:4 (2001).  A relatively mathematical treatment but very clear and rigorous.
* "Practical Impact of Group Communication Theory."  Andre Schiper.  Future Directions in Distributed Computing.  Springer Verlag Lecture Notes in Computer Science 2584 (July 2005).  Talks about the history of data replication and fault-tolerance; very balanced and suitable for a non-expert.
* "The part-time parliament".  Leslie Lamport.  ACM Transactions on Computing Systems (TOCS), 16:2 (1998).   Introduces the Paxos protocols, one of the three main classes of replication techniques.  Some may find this hard to follow; the mathematical notation is a bit dense.
 
* "A review of experiences with reliable multicast" Software, Practice and Experience.  29:9 (July 1999) K. P. Birman.  Describes some case-studies including stock exchanges, air traffic control systems.    
* "Exploiting virtual synchrony in distributed systems". K.P. Birman and T. Joseph.  Proceedings of the 11th ACM Symposium on Operating systems principles (SOSP), Austin Texas, Nov. 1987.  First use of the term, but not necessarily the easiest source for learning more.
-—Preceding unsigned comment added by Ken Birman (talk • contribs)  08:14, 7 June 2007 (UTC)
thread_title:  External Links 

message: Can anyone help with the formatting of the 3 figures in the section that illustrates virtual synchrony using time-line diagrams?  These seem too small in the gallery format, but are too large to include in-line.  I'm happy to do the work if you want to suggest a particular way of doing this but don't feel like doing it yourself. Ken Birman 16:33, 13 June 2007 (UTC)
thread_title:  Help needed for the illustrations 

message: For about six months now, this page has been tagged for Point of View, Original Research and Factual Accuracy. After a brief period of discussion and editing activity, nothing has happened for six months.
Here's my question: as a matter of policy, do such tags remain on the page forever, or is there some procedure for agreeing to remove them? It seems safe to assume that KPBotany, who placed them there, would not consider the matter resolved, since nothing substantive changed during this period. However, perhaps that particular reviewer will never find comfort with this material -- such things do sometimes happen.  Ken Birman (talk) 18:03, 21 December 2007 (UTC)
replies: text: Ken, such tags are a matter of local consensus. As most of the text has been contributed by one person, namely you -- the author of Virtual Synchrony, the OR, POV, and FA tags should probably remain. Its too bad that no one stepped up to the plate to help with the editing. Perhaps you can attract attention of editors on the Paxos algorithm page as they might be interested in the topic and would probably do a good job as that particular article has become much better over the last year or so.Bestchai (talk) 03:26, 25 January 2008 (UTC)

text: Perhaps this article could be condensed into an automatic way to resolve an edit conflict. When I was introduced to dumb terminals in 1988, two people could not write to the same file at the same time. Now, I can almost see a way where this could usually be automatic. IOW, if two people did not alter exactly the same text in a file. In an edit conflict, current wiki software sends one user's edit to another. It's a lot of work to do that stuff manually. Know what, though? If two users do write into the same bytes, then one needs more authority (latest submission--timeouts in effect). As wiki is, now, I would prefer to serialize write locks, like they used to. event queue seems to be majorly relevant. BrewJay (talk) 09:25, 14 July 2008 (UTC)
replies: text: In fact this topic has been studied (the most famous work is by Jerry Popek, years ago in a system called LOCUS (sadly, he just passed away last week), and more recently by Doug Terry at Xerox Parc and then Microsoft.  Microsoft has a new file system under wraps that does exactly what you have in mind.  Very very cool.  And definitely related to the topic of event ordering and time in a distributed system.  A bit less specifically related to virtual synchrony, though. Ken Birman (talk) 14:17, 9 August 2008 (UTC)
thread_title:  Protocol for removing tags? 

message: IMHO, this article is still deeply flawed.  Most importantly, there are fundamentally
different assumptions between virtual synchrony and other algorithms (e.g. Paxos).
Specifically, virtual synchrony has stronger assumptions about delivery of 
messages - it seems to me that this can only be guaranteed (with unreliable
network transports) by extra acknowledgement messages.  Thus the claimed
performance gains of virtual synchrony are achieved by sleight of hand.
DrInequality (talk) 00:00, 8 August 2010 (UTC)
replies: text:  It would help if you could be very specific about your concern, since this is written in a general way and I don't know what line you are referring to (or, if referring to a published paper, which paper and which lines within that paper).  But the broad answer is that you are incorrect, although the question is a sensible one to pose.  Virtual synchrony makes exactly the same assumptions about message delivery as Paxos.  Clearly something has caused you to be confused either about Paxos or about virtual synchrony.  Both of them require a layer that sends acknowledgements and does flow control and congestion control; this isn't really an "assumption" or "slight of hand" but just a form of layering: first, you deal with reliability on a point-to-point basis, and then you layer your more elaborate protocols over these point to point ones.  But we don't assume anything -- in particular, we don't assume that the recovery mechanism will be successful.  Thus a protocol instance could try and try to send a message from A to B, over this layer, and yet the message being sent might never get through, even though both A and B are running (the network could be "partitioned", to use a technical term).  In such cases we force a reconfiguration: either the sender will end up exiting, or the destination will be removed from the system, based on a majority vote within the membership service, which itself is built over exactly the same unreliable message passing layer.  At any rate, no slight of hand, and in fact not only is the model identical, but Dahlia Malkhi has written a very nice paper in which the two models are merged into a single more general model (but the assumptions remain unchanged).  This paper is available from the MSR technical reports web site (look for Birman, Malkhi and Van Renesse) or the Cornell web site (http://www.cs.cornell.edu/projects.quicksilver/pubs.html) and is quite formal; indeed, we've used a mechanical theorem prover called NuPRL to automate the model and to verify proofs within it. Ken Birman (talk) 00:41, 22 November 2011 (UTC)
thread_title:  Article still biased? 

message: This article requires better illustration by figures (compare with the Paxos alg page to see what I mean).  It should show standard operation messages and typical failure cases.  This is a key requirement for this type of article.  DrInequality (talk) 00:04, 8 August 2010 (UTC)
thread_title:  Better figure(s) required 

message: I think JGroups should be added.  Thoughts?  — Preceding unsigned comment added by Sourcedelica (talk • contribs) 11:23, 2 October 2014 (UTC)
replies: text: Absolutely.  But it isn't a sole-editor situation, so if you mean I should do that edit, I prefer not to:  I wrote the first version, quite a while ago.  Now you own it; the best response to conflict of interest is to have other people do the future edits.  So go right ahead!  JGroups does use the same model (it originated as a Java rewrite of Horus, actually).  So, totally appropriate suggestion, and I encourage it.    Ken Birman (talk) 22:45, 21 October 2014 (UTC)
thread_title:  Other references