Language:
switch to room list switch to menu My folders
Go to page: 1 3 4 5 6 [7] 8 9 10 11 ... Last
[#] Wed Sep 17 2014 08:54:09 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Lazy programming.

[#] Wed Sep 17 2014 15:10:35 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Sep 17 2014 20:13:01 EDT from Sig @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Sep 18 2014 04:53:11 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Sep 18 2014 07:19:10 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Sep 18 2014 18:42:14 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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)

[#] Thu Sep 18 2014 18:43:22 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Sep 18 2014 18:44:38 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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 ;-)

[#] Thu Sep 18 2014 18:53:18 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Sep 18 2014 20:03:19 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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"

[#] Thu Sep 18 2014 21:51:55 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hrm... are you not at risk of a malicious attack where someone consumes all your accepts?  I thought you might timeout and drop the connection, but if you aren't...?



[#] Thu Sep 18 2014 21:53:54 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Sep 17 2014 20:13:01 EDT from Sig @ Uncensored
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.

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.



[#] Fri Sep 19 2014 19:10:58 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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

[#] Fri Sep 19 2014 23:55:42 EDT from Sig @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Sat Sep 20 2014 10:29:45 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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

[#] Sat Sep 20 2014 10:29:59 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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

[#] Sat Sep 20 2014 11:14:19 EDT from Sig @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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."

[#] Sat Sep 20 2014 20:38:54 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Mon Sep 22 2014 01:22:56 EDT from ax25 @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Sat Sep 20 2014 08:38:54 PM EDT from LoanShark @ Uncensored
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.

I am just now jumping on another "opportunity" to do the same.  Thanks for the kind reminder LS!  Just because I am old, does not mean I can learn Android OS programming :-)



[#] Mon Sep 22 2014 08:17:45 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


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."

Go to page: 1 3 4 5 6 [7] 8 9 10 11 ... Last