[Time] Name | Message |
[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
|