
Category: Uncategorized
TCPMUX – a mostly overlooked TCP service
TCPMUX is described in RFC-1078 (written some 20 years ago). A reference implementation by Network Wizards can be found at ftp://ftp.nw.com/nw/software/tcpmux.c . It is also implemented in DragonFlyBSD’s inetd, NetBSD’s inetd and FreeBSD’s inetd. OpenBSD does not support for it.
The Protocol
A TCP client connects to a foreign host on TCP port 1. It sends the service name followed by a carriage-return line-feed . The service name is never case sensitive. The server replies with a single character indicating positive (“+”) or negative (“-“) acknowledgment, immediately followed by an optional message of explanation, terminated with a . If the reply was positive, the selected protocol begins; otherwise the connection is closed.
The 15+ years I have been a sysadmin I have never seen anyone making a use of it, which is a pity: Most of the time I see fellow sysadmins who want to write a custom daemon, either write it as a standalone server (usually starting with passivesock.c or passiveTCP.c from Comer’s Internetworking with TCP/IP vol.3), or writing is as a simple stdin/stdout application that is started via inetd. The most trivial problem is sometimes more than trivial:
– What port will this application run on?
It seems that 65535 ports is a lot of freedom to choose from and most people want to use “interesting” port numbers (for any definition of interesting). Add firewall policies and router access lists in the picture, you can have a non-technical deadlock in no time!
TCPMUX might be a choice to help simplify / avoid such situations. Any service that supports TCPMUX listens on port 1/tcp and can be forked by inetd(8) (either internally or externally with the help of a tiny server). After all, it can be considered as an “inetd inside inetd” (the classic inetd responding to requests on a port, TCPMUX responding to requests based on the name of the service) and even if you do not want to use TCPMUX, a similar (homegrown) solution might be the answer to keeping your packet filters lean and less complex. It does not have to be less complex than it has to be though. The Wikipedia article on tcpmux clearly identifies risks that come with deploying it. Personally, I view tcpmux as an old and simple TCP RPC mechanism.
Appendix: tcpmux.c
Since the Network Wizards site seems to be down / taken over by some other entity, here is the original tcpmux daemon code (also at github https://github.com/a-yiorgos/tcpmux ):
c-client callbacks
* This is mostly for personal copy-paste reasons
Those who take the time to develop applications using UW-IMAP (or Panda IMAP) know that there are a number of callbacks that need to be defined. What follows is the simplest (do nothing) version of them.
#include "c-client.h"
void
mm_flags(MAILSTREAM *stream,unsigned long number) {
}
void
mm_status(MAILSTREAM *stream,char *mailbox,MAILSTATUS *status) {
}
void
mm_searched(MAILSTREAM *stream,unsigned long number) {
}
void
mm_exists(MAILSTREAM *stream,unsigned long number) {
}
void
mm_expunged(MAILSTREAM *stream,unsigned long number) {
}
void
mm_list(MAILSTREAM *stream,int delimiter,char *name,long attributes) {
}
void
mm_lsub(MAILSTREAM *stream,int delimiter,char *name,long attributes) {
}
void
mm_notify(MAILSTREAM *stream,char *string,long errflg) {
}
void
mm_log(char *string,long errflg) {
}
void
mm_dlog(char *string) {
}
void
mm_login(NETMBX *mb,char *user,char *pwd,long trial) {
}
void
mm_critical(MAILSTREAM *stream) {
}
void
mm_nocritical(MAILSTREAM *stream) {
}
long
mm_diskerror(MAILSTREAM *stream,long errcode,long serious) {
}
void
mm_fatal(char *string) {
}
ΤΣΜΕΔΕ pain
Quick note on Lattices, Relations and stuff
Thanks to @mosabou I got to read about Formal Concept Analysis. What a cool concept! Of the first things that I read was “A First Course in Formal Concept Analysis” (an introduction to the subject without the mathematics). While going through the examples, I kept thinking Where have I seen that before? Relational Databases, that’s where! And it seems that my intuition was correct: see the excellent “Gentle introduction to Relational Lattice” by Vadim Tropashko and the links from there.
[ I vaguely remember Yannis introducing the lattice concept in a database context in a course lecture a few years back, but have to admit of not looking much into it back then. ]
This is mostly a note for people who insist on thinking that theory is disconnected from practice. Especially the ones who write SQL code and insist on not realizing that they deal with sets (and set theory). Stop holding an umbrella and invest some time in your math.
downsizing
* Initially this post was started because of Sun’s layoffs (18%). Now Sun is no more, and so seems work for a large percentage of the Greek workforce.
Downsizing is to be expected in great numbers. At the scale that this seems it is going to happen, these will not really be informed layoffs, the criteria being simple: You have a high salary (for some definition of high) and your choices may include: retirement, layoff, substantial pay-cut (equals to morale / motivation downsizing) and/or transfer to another organization (in a take it or bye-bye offer).
The short term result of such a massive violent move will of course be proof of elimination of the so called “cost centers”. The mid and long term results will be far more different: The information flow within the organizations will be severely disrupted. There exists the organizational structure and then there exists the informal structure that gets built over time. The departure of a key person can be dealt with by an “unconscious” team auto-configuration. But what about more than one? While small teams communicate more effectively, small teams cannot be made smaller. Time is a limited resource and there is not enough to perform the required analysis before downsizing.
That is the price to be paid for not trying to be lean when you had the chance. And new “cost centers” will emerge.
Appendix: Chalk one up for math (or How even retirement disrupts information flow)
Steinmetz‘ most gratifying moment may have occurred after his retirement. An emergency brought him back to GE’s Schenectady plant to troubleshoot a malfunctioning generator. For days, the hobbled genius pored over drawings with paper and pencil in hand. Finally, he placed a chalk mark on the side of the generator, instructing the repairmen to cut through the casing and remove a number of turns from the stator. It worked.
When asked to submit an invoice, Steinmetz delivered a slip of paper with nothing on it but the surprisingly large figure of $10,000. The accountants, in shock, said they couldn’t process the paperwork without a more detailed breakdown. Steinmetz then forwarded another note on which was typed:
One chalk mark $1. Knowing where to put it $9,999.
A short time later, Steinmetz received his pay in full.
To those that believe that this was not because of disrupted information flow, but because of Steinmetz’ genius, I can only say that I know of cases where retired for decades engineers were called back for consulting due to lack of documentation. And today’s knowledge workers are not better at keeping it either.
On vendor lock-in
(and sometimes open-source vendor lock-in)
Thanks to @nzaharioudakis (whom I had asked whether Debian stable is an adequate platform to run Zimbra on) I remembered the following quote from “Conquest in Cyberspace“:
“The seducer, for instance, could have an information system attractive enough to entice other individuals or institutions to interact with it by, for instance, exchanging information or being granted access. This exchange would be considered valuable; the value would be worth keeping. Over time, one side, typically the dominant system owner, would enjoy more discretion and influence over the relationship, with the other side becoming increasingly dependent. Sometimes the victim has cause to regret entering the relationship; sometimes all victim regrets is not receiving its fair share of the joint benefits. But if the “friendly” conquest is successful, the conqueror is clearly even better off.”
Even though the above is written in cyberwarfare (political) language, the point is very clear and the IBM executive’s phrase becomes well understood:
“Because you don’t want to get locked into an open system”
(One has to keep in mind that the phrase is taken somewhat out of context. Some 20 years ago when he spoke of “open systems” he meant OSI).
I do not want to get locked in any system.
→ “You ALWAYS pay“
kid[0] in action
The ΤΣΜΕΔΕ saga
Ευτυχώς αυτή τη φορά είχα μαζί μου το BeBook Mini…
On a side note, έμαθα πως εκτός από το www.tsmede.gr, το www.tsmede.eu υπάρχει και το www.etaa.gr
Autism’s False Prophets
I love “Cantor’s Dilemma“. In its final chapter (#22) a letter exchange between two powerful characters describes politics in Research in the most clear way. The book has one problem though. It is fiction.
“Autism’s False Prophets” by Paul Offit is not. It covers the various vaccines-cause-autism theories and provides scientific data that prove them wrong. Do you want to read about bad science? It is there. Do you want to read about non-repeatable experiments? It is there. Do you want to read about how people mistake correlation for causation? There too! Do you want to find out how charlatans of any background take advantage of desperate people? Read the book. People want to be heard and want (instant) relief. With science not having the answers (or answers they can accept and deal with) charlatans step in loudly and fill the void. As is written in the book, hope is the best fix, better than any drug on the street.
“An easy-to-read medical thriller about the consequences of greed, hubris and intellectual sloppiness” reads the back of the book. This is a a chronicle and a science thriller, not a science fiction or science-in-fiction work. It contains the best explanation of the scientific method and the Null Hypothesis for the general public. Thanks to the book I now understand why the most illiterate and unscientific show ever presented on Greek TV exists:
“Unfortunately, the motivations of scientists who perform studies differ from those in the media who describe them: one wants to inform, the other to entertain.”
People want quick answers and are easy to jump to conspiracy theories that can provide them. It is no wonder that the opinion of journalists, ministers, politicians and celebrities that “attended the University of Google” gets accepted as expert opinion by the general public while the scientists are hiding “The Truth” by being on the payroll of big corporations. After reading the book I still do not understand why some people (the very same people that subscribe to such theories) do not visit their personal-injury lawyer every time they have a headache.
While if one is not directly involved with autism the book can have a few boring corners, it is a guide on how to present the facts. It is no wonder that the author gets so much hate mail and is the recipient of death threats.
PS: Two very interesting web sites that the book recommends are neurodiversity.com and
JunkScience.com.
