[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Bug#458819: ITP: nettee -- a network "tee" program




"Joel Franco" <joel.franco@gmail.com> wrote in message 20080106020045.GA8203@netuno">news:20080106020045.GA8203@netuno...
- simplicity: like you already said, the simple command, without complex
 pipe setups like showed in your example comments. You have to agree
 with me that that netcat + tee pipe commands are not trivial. If I
 had known about that commands, i will not have searched for somenthing
 like nettee in Google.

Good point. However, while it did take me a few minutes to cook that up, was still reasonably simple piping. The biggest trick was the '>(...)' syntax, and knowing the arguments to use for netcat. The rest was simple pipes and input/output redirection. Definately not trivial, but not too terrible either. Command line plumbing can be much more complicated (although very complicated plumbing is honestly rarely ever useful). But you said something very important, that I somewhat hoped you would say. You did seach for a utility because you did not know how to do it manually. That there is an important advantage to a package. In particular, having the manpage to document things.



- multiple target: you can specify multiple targets to send the stream
 and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
 Ok.. ok.. you can make it with a complex pipe; i just can say that
 i will say again the previous argument.

You can indeed do that with complex piping, although it definately begins to get very large and hard to deal with. This is a useful advantage of such a package.


- error check in the stream data: there is a check for transmission
 errors in the code. This is util when there are failed nodes.

Yes it is indeed a useful benefit that definatly difficult to do with just tee and netcat.


- error handling while data is being transmited: there is a lot of
 options to the chain not die if there is a single node failure. In
 your pipe commands, if one node die, the full chain is lost.

Yes, indeed. That is a real downside to chaining like that. And something that a dedicated program can handle much better.

Your defense of the program here was quite good, as it does clearly show the benefits of such a program. A useful skill to have as a package maintainer. Futher, I now know to look for that utility if I ever have such a need. :D

In short, simplicity and error check.

If you liked, can you be my sponsor? :)

Unfortunately, I cannot, as IANADD.



Reply to: