Lazy programming.

Esp. in posix oses, one would approach working with a network socket

like one would approach working with a file handle. And operations
that flush output to a file handle would naturally be expected to flush

output out a network socket.

Setting out to learn sockets programming without reading the Stevens book is dangerous.

Even more dangerous, however, is the newb who sees the behavior of TCP stacks discarding data on close, and instead of simply modifying his program to wait for an acknowledgement from the other end, decides to write his own "better than TCP" alternative.

The last programming I did was in Turbo Pascal in 1995, and it was not exactly a stunning success; so much so that I concluded I simply wasn't capable of programming. I'm still having fun with python; I'm almost done with the codecademy stream. I might finish that tonight if I can talk the kids into watching a movie or something. I had all sorts of plans for my Beaglebone Black, but at the moment it is just running an instance of ipython so I can have access to my notebooks on whichever computer I feel like using.

IG:

I've been working on a project for my company that involves some HTTP transfers.
Another person working within the company is working on an almost identical project on behalf of the government, meaning that the government will keep all of that code. I was hired specifically to allow my company to keep the code that we're writing, potentially writing a patent or two for it.

The other guy is frustrated that the cannot just 'flush the socket' when sending data over TCP/IP. He doesn't want to 'write a protocol' because 'protocols are inherently difficult'.

He considers prepending TCP output with a size and waiting for acknowledgement enough of a protocol that he doesn't want to risk doing it.

So, instead, he relies on calling using a TCP shutdown message to help indicate that the packet is done, and waits for the other end to close. Which, I suppose, will work but... it seems like a very brittle approach when a very simplistic protocol isn't actually that difficult to accomplish.

Apache has a "lingering close" socket function which does something similar.
LoanShark wrote a similar version for WebCit, and it's been in its current state for a decade and a half without breaking.

[ http://tinyurl.com/wc-ling-close ] if you want to take a peek at our implementation.

2014-09-16 19:38 from LoanShark @uncnsrd

Why, oh why must IntelliJ's rebase/merge window be MODAL?!?

Batshit insane.

Apparently it also causes IntelliJ to spin and eat 100% CPU until you finish your merge. I had to leave it in the modal overnight (grr) because shit was complicated. So I couldn't access my windows for unrelated projects that were not involved in the merge... (durrr)

Even more dangerous, however, is the newb who sees the behavior of TCP

stacks discarding data on close, and instead of simply modifying his
program to wait for an acknowledgement from the other end, decides to

write his own "better than TCP" alternative.

You're onto something here. What happens if the acknowledgement is discarded on close.

The other guy is frustrated that the cannot just 'flush the socket'
when sending data over TCP/IP. He doesn't want to 'write a protocol'

because 'protocols are inherently difficult'.

What a dingus. It's a good thing he's working on the goobermint side--also no surprise ;-)

Apache has a "lingering close" socket function which does something
similar.
LoanShark wrote a similar version for WebCit, and it's been in its
current state for a decade and a half without breaking.

Whoa. Forgot about that. Not sure if current versions of Apache still do it that way...

I'm still waiting for SO_MALINGER to fix the problem.

Whoa. Forgot about that. Not sure if current versions of Apache still

do it that way...

Not gonna bother looking at their code, but I'll bet it's still there and gets called when HTTP/1.0 is in use and/or when "Connection: close" is specified.
Otherwise the server socket hangs out and the client will close when it damn well feels like it!

WebCit doesn't implement "Connection: keep-alive" in order to keep the code path simple, so the lingering close code will forever be in a state of "don't f***ing touch this; LoanShark got it right and you can't make it better"

Not gonna bother looking at their code, but I'll bet it's still there

nginx thinks they are smart enough to identify protocol states where it's not needed ;)

http://mailman.nginx.org/pipermail/nginx-devel/2011-July/001016.html

Good programming stands on a mountain of failure.  A good programmer
is someone who has failed in just about every way imaginable, but
didn't give up.

Perhaps, but so does terrible programming. Regardless, it amuses.

Well, I suppose a distinguishing difference between those two programmers would be that the good programmer learns from those failures.

(The bad one doesn't so much stand on those failures, but swims in them).

It's pretty hard to "fail" at Codecademy.com streams, but you can not-succeed for a fair while.

I had all sorts of plans for my Beaglebone Black, but for right now it's a full-time part of my network, hosting my ipython notebook. I may have to buy a few more of these things for radio and "other."

Good programming stands on a mountain of failure.  A good programmer

That and hubris. To tackle a large, complex project, you really need a completely undeservededly rosy view of your own competence.

Heh... hubris...

When confronted with a gigantic project, my first reaction is, "oh shit," followed by, "oh, but I've gone through this kind of thing before," which leads to, "break it down to smaller bits and focus on them, or I'll be consumed by the enormity of it all."