IRC Log


Friday April 16, 2010

[Time] NameMessage
[07:53] CIA-5 zeromq2: 03Martin Sustrik 07master * rd524c4e 10/ doc/zmq_setsockopt.txt : fix of documentation typo - http://bit.ly/cawYnX
[08:21] mato mikko: that patch looks good to me, yes
[08:21] mikko mato: is sed -i portable?
[08:21] mikko or is it gnuism
[08:29] mato mikko: the POSIX manpage for sed doesn't mention -i
[08:29] mikko bummer
[08:30] mikko sed .. orig > f.tmp && cat f.tmp > orig && rm f.tmp i guess
[08:31] mato something like that; i did use RPM packaging on non-Linux systems years ago but i wonder if anyone else does that :)
[08:33] mikko i would think it would be safe to assume gsed for now
[08:33] mikko "there is gnuism in linux build files" kinda makes sense
[09:37] mikko redhat packaging sent to lists
[09:38] mikko let me know if anything else is needed, i got full day of meetings but should be back this evening
[09:40] mato will do, thanks
[11:17] sjampoo I know hardly anything about multicast, but zmq makes it so easy to use. Are there any pointers somewhere with more information about multicast?
[11:17] sjampoo Specifically recommendations / its limitations?
[11:18] sjampoo I am afraid i'll run into problems when i create lots of multicast channels, but don't know if there is any reason to.
[11:19] sjampoo fe, i read somewhere that a NIC can handle 15 addresses fine but will into problems when needing to handle more than 100.
[11:21] sustrik sjampoo: multicast is not easy to manage
[11:21] sustrik if you don't really need it don't use ti
[11:21] sustrik it*
[11:23] sjampoo aha, so i really should invest some time in the app logic instead of just dumping it on the network.
[11:26] sustrik ok, multicast:
[11:26] sustrik 1. only on LAN
[11:26] sustrik 2. use it only if your traffic exceeds the capacity of the LAN
[11:26] sustrik 3. you need high-end networking harware
[11:27] sustrik 4. you can still easily kill your network by overloading it with multicast packets
[11:28] sustrik 0mq makes it easy NOT to use multicast, simply use PUB/SUB sockets on top of TCP and what you get is basically multicast semantics
[11:30] guido_g for the price of higher system load, one should mention that
[11:30] sjampoo I agree with that, but you still need some sort of DS to manage the socket connections, when using multicast you could just dump it on a channel and let the network figure it out. That makes it so tempting.
[11:31] guido_g what about something unicast on top of udp? would at least make lots of subscriptions more ressource friendly, wouldn't it?
[11:37] sjampoo ill stay away from multicast for now, thanks for the info
[11:37] sustrik sjampoo: you can do the same thing with PUB socket, no? Just dump your data to the socket and let 0mq do the work
[11:37] sustrik you are welcome
[11:39] sjampoo sustrik, well with multicast you could have 2 servers publish to a channel and a single subscriber all without extra logic
[11:39] sjampoo In unicast you need to subscribe to the 2 servers
[11:39] sustrik ah, multicast bus
[11:39] sjampoo yes, thats really tempting
[11:39] sustrik consider that that moves a lot of logic to your application
[11:40] sustrik who does the message come from?
[11:40] sustrik what should i do with it?
[11:40] sustrik what if one of the senders fails while i am in the middle of transaction
[11:40] sustrik etc.
[11:42] guido_g sorry for my ignorance, but the other transports also have issues w/ the probs shown, right?
[11:43] sjampoo Doesn't zmq take care of the nasty parts already?
[11:44] sustrik what i meant is that several publishers publishing to the same "group" is almost an antipattern
[11:44] sustrik it can be used in some constrained scenarios
[11:44] sjampoo i am thinking about distributed logging fe
[11:45] guido_g ahh, here the bus semantic is really useful, imho
[11:45] sustrik well, then you have just one logger no?
[11:45] guido_g no
[11:45] guido_g think about specialised clients that do filtering, storing etc.
[11:46] sjampoo exactly
[11:46] guido_g i.e. one could attach a special looger to the system to find a bug w/o changeing hte behaviour of the system
[11:48] sustrik sure, if you don't care about system producing log messages all the time, even when not needed, it should work
[11:48] guido_g this is what's recommended anyway
[11:49] guido_g most of the larger sites don't have log-levels anymore, when it's true what's published about them
[11:50] guido_g infoq.com and highscalability.com do have articels/videos about that topic
[11:51] sustrik feel free to post the links on the mailing list
[11:51] guido_g ok
[11:51] guido_g does posting via gmane work? i'm reading via gmane
[11:52] sustrik no idea, give it a try
[11:52] guido_g i'll do
[13:20] sustrik guid_g: no lock?
[13:20] sustrik luck*
[13:21] guido_g sustrik: lock?
[13:21] guido_g luck with what?
[13:22] sustrik sending the email?
[13:22] guido_g if you meen the links, i just came home from work and started the search
[13:22] sustrik :)
[13:23] guido_g http://delicious.com/guido_g/logging <- in principle :)
[13:23] guido_g but i'll write a wrap-up
[13:24] sustrik thanks
[14:18] guido_g sustrik: news posting sent
[14:33] sustrik nothing arrived yet.. let's wait a while
[14:33] guido_g yep, sure
[14:37] guido_g btw, we talked about lots of servers, right? this is the current status of _lots_: http://www.intac.net/a-comparison-of-dedicated-servers-by-company_2010-04-13/ :)
[14:42] sustrik still, if all the 1M google servers would start logging using multicast :)
[14:43] guido_g hmmm...
[14:43] guido_g at least, multicast would be much more prominent then
[15:02] jomofo Is something akin to TLS out of scope for 0MQ? (Just performing thought experiments to better understand the architecture)
[15:02] sustrik jomofo: what's the idea?
[15:05] jomofo sustrik: Just thinking for a health care application or something along those lines you might want authentication and encryption on the wire. Just wondering if it's within the architectural constraints of 0mq to provide a TLS transport, or if this is something you need to do in the application protocol
[15:05] jomofo Not really an enhancement request, per se, but just trying to wrap my head around some of the abstractions
[15:06] mikko the question about TLS seems to come up fairly often
[15:07] sustrik yep, but i'm not the right person to ask, i have very little security experience
[15:07] sustrik maybe discussing it on list would help?
[15:08] jomofo sure, i'll send something to the list