From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df10904280729i4b91c1ebi20d75fc59a64f94c@mail.gmail.com> References: <13426df10904271740x193e2987r86cd11ca840c2080@mail.gmail.com> <13426df10904280729i4b91c1ebi20d75fc59a64f94c@mail.gmail.com> Date: Tue, 28 Apr 2009 16:17:02 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] just in case anyone has written this Topicbox-Message-UUID: f40b102c-ead4-11e9-9d60-3106f5b1d025 2009/4/28 ron minnich : > On Tue, Apr 28, 2009 at 2:05 AM, roger peppe wrote: >> 2009/4/28 ron minnich : >>> On the inbound side, I need it to merge lines so that, e.g., a line from >>> 11.1.1.1 and 11.1.1.2 if same, gets printed as >>> 1-2: Mon may 8 2011 >> >> if you do this, then presumably you can't print a line >> from any source until you've got a line from all of them. >> is that what you want? or does the merging apply only >> to lines received within some time interval of each other? > > you have to have a timeout (which I do) since nodes can always fail or > not talk to you if one node is just slow enough in responding that it falls outside the timeout, you could get an annoying situation where that node is out-of-step forever after. i guess it depends how often incoming lines arrive. if it's an interactive session, i guess it might not matter too much - i can see how this might be useful controlling many shell sessions at once. you could make things more reliable by tagging requests and replies, but even then there's the question of what to do when sessions diverge (assuming that's what you're doing). interesting.