Monday, December 31, 2012

Long emails

I have an article about writing effective long emails.

Those of you who know me are already rolling your eyes; I am well-known for writing long emails.

Why do I do it?  I don't know if it's an egotistical pleasure in seeing my own verbosity, or if there is a genuine desire to leave the world a little better than how I found it.  At this point in my life, I don't need to know why.  I'm an email novelist, and that's that.

One thing I've learned is that a long email is a waste of time if it is not effective.   I've spent many an hour fussing over a work of art, only to discover that nobody read it.  Sound familiar?  If so then you may benefit from my article:

Sunday, December 2, 2012

Multicast Oddities

The operation of multicast is standardized, well-defined, and well-understood.

Or is it?  (Insert ominous music here)

RFCs and other standards mostly apply to packets as they traverse the network.  Network administrators take care of multicast infrastructure so that software developers usually don't have to worry about the subtleties of multicast connectivity and routing.  However, what the operating system does inside a host is often not governed by formal standards.  There are some corner cases related to multi-homed hosts where operating systems behave in non-intuitive or inconsistent ways that the software developer must be aware of.

In the scenarios shown below, we tested multicast connectivity with a set of simple multicast tools "msend" (for sending) and "mdump" (for receiving).  See mtools for source and binaries for these programs.  In all cases, the msends and mdumps use the same multicast groups and destination ports.  The testing was done on four operating systems: Linux, Solaris-10, FreeBSD, and Windows.


In this scenario, two interfaces are used, one for sending multicast packets and the other for receiving them.  In particular, this scenario assumes that the two networks attached to the interfaces are not routed, at least not for multicast.

The results of testing the scenario are what you would expect - the mdump does not receive the traffic.  This is true for all four operating systems.

No surprise here, right?  Well, hang on tight; things are about to get more interesting.


In this scenario, the two networks are routed.  I.e. multicast packets sent to network 1 are routed to network 2.  One would expect that the mdump would now receive the packets, right?

It does for Solaris-10, FreeBSD, and Windows.  However, when tested with Linux, the mdump stays silent.  We ran "netstat -g" and the kernel thinks it is joined to the multicast group on Network 2, and a "tcpdump" (with promiscuous mode turned OFF) indicates that the packets are, in fact, being received by the kernel.  But for some reason, the Linux kernel is discarding those packets.

I, for one, consider this to be a bug in Linux.  It violates application portability.  That is, if the mdump is run on a separate machine connected to network 2, the packets are received just fine.  But run it on the same machine as the sender, and it stops working.


In this scenario, a second mdump is added, joining network 1.  One would expect both mdumps to receive the multicast, and in fact they both do.  So the only surprise here is that mdump2 appears to have "fixed" the Linux bug in scenario 2.


Things here get interesting again.  Back to an unrouted scenario, with the second mdump.  One would expect mdump2 to receive the data but not the original mdump.

This is what happens for Solaris-10 and WIndows.  For Linux and FreeBSD, *both* mdumps receive the data.  I consider this to be a bug for Linux and FreeBSD - why should an additional mdump change the behavior - but I consider it less serious than scenario 2's problem.  In scenario 4, the problem is receiving more packets than expected, which could be filtered out by the application.

So, when dealing with multi-homed hosts, it is usually advisable to stick to a single interface if the networks are routed, or to use different multicast groups on each network if non-routed networks are used.

(BTW, this article was first published in 2009 on a different, now deleted, blog.)

LinkedIn Endorsements

LinkedIn Endorsements: you've probably received some.  Maybe you've given some.  I'm pretty much ignoring them.

I've been endorsed for software skills by people who have no software experience.  Friends and relatives endorse each other even though they have no first-hand experience with that person's skills.  It's like measuring a person's likability based on how many times they've been "liked" on FaceBook - it has more to do with the number of people you're connected to.  Popularity is not a measure of skill mastery.

The cynical part of me thinks LinkedIn created them as a mental virus for the sole purpose of getting people to sign in more often, so they can get their ads to more eyeballs.  (The cynical part of you might be saying, "Duh!")  Similar to chain letters, the system asks you to endorse your connections, which sends emails, which prompts those people to sign on and issue endorsements.

All that said, I don't want to be antisocial.  If you want me to endorse you for anything, let me know; I'll click as many skills as you like.  And thank you for the good thoughts behind your endorsements of me.

Just don't use LinkedIn endorsements to evaluate my technical skills.

FYI - I consider LinkedIn recommendations to be different.  Although they are susceptible to the same "you scratch my back, I'll scratch yours" reciprocity, I do consider them more useful then endorsements.  For one thing, there's a bit more accountability - your name is on your recommendation.  Also, they contain more information than a simple check mark.


Ok.  I surrender.  I went through my whole list of contacts and basically gave everybody a bunch of endorsements.  I still think they are of near-zero value, and I won't ever use them to evaluate somebody else's experience.

I guess they're kind of like valentines - sure, we all know that Valentine's day is a manufactured holiday, and is commercialized, and it's more "real" to show your love through non-scripted acts, and blah blah blah.  But you know what?  SUCK.  IT.  UP.  Give the damn Valentine card, along with a pot o' posies or a box o' chocs.  Its not rational, but since when are humans bastions of rationality?  It's just a form of social currency that you ignore at your own peril.

So yeah.  I've gone through my whole list and given lots of endorsements.  (And I got a flurry of them in return.)  One more form of social currency to contend with.