Beej Jorgensen @ beejjorgensen @lemmy.sdf.org

Instructor, author, developer. Creator of Beej's Guides.

---

Read more

Posts

5

Comments

381

Joined

2 yr. ago

"Unless you give us all your money to put in our new bank, we might be facing insolvency issues."

So the page says:

And this does in fact happen - even though some of your data was still waiting to be sent, or had been sent but not acknowledged: the kernel can close the whole connection.

But Stevens says:

By default, close returns immediately, but if there is any data still remaining in the socket send buffer, the system will try to deliver the data to the peer.

The SO_LINGER socket option lets us change this default.

And, referring to the default close behavior:

We assume that when the client’s data arrives, the server is temporarily busy, so the data is added to the socket receive buffer by its TCP. Similarly, the next segment, the client’s FIN, is also added to the socket receive buffer (in whatever manner the implementation records that a FIN has been received on the connection). But by default, the client’s close returns immediately. As we show in this scenario, the client’s close can return before the server reads the remaining data in its socket receive buffer. Therefore, it is possible for the server host to crash before the server application reads this remaining data, and the client application will never know.

Also:

If l_onoff is nonzero and l_linger is zero, TCP aborts the connection when it is closed. That is, TCP discards any data still remaining in the socket send buffer and sends an RST to the peer, not the normal four-packet connection termination sequence.

I'm having trouble reconciling this with the article's position that data will be discarded by the sender OS with a plain non-SO_LINGER close().

I can see how the sender might be blissfully unaware that the receiver program might have crashed after the data had been sent and the connection had been closed, but before the data had arrived at the receiver program. And that's where some kind of application ACKing mechanism might be in order.

I can also see that the receiver OS might happily collect the data and shutdown the socket correctly and then the sender app thinks everything is fine, but the receiver app has crashed and will never see the data.

But neither of those conditions result in the receiver app in the example showing less than 1,000,000 bytes received unless there's an error.

What am I missing?

That Doctorow essay seems appropriate: https://pluralistic.net/2023/07/28/microincentives-and-enshittification/

For sure--I just don't tend to watch anything more than once. :) Most of my federated identity and offsites are at SDF, which is a solid place with a mission I respect and certainly don't mind giving $36/year to. Grayjay for stupid vids (if I could just get it to work with FCast...)

Depends on your definition of "evil", I guess.

Might get there. Right now I just have external SSH access (key only) to get to the files. I also need an offsite, so it's all sent to a remote server with rsync and gocryptfs. I only have about 90 GB of stuff on there right now; I don't do any media serving.

https://archive.is/tCWIM

I took my money from YouTube and started giving it to Kagi. 🙂👍

I'm a gray developer and nothing makes me more get-off-my-lawn than too many levels of abstractions. :)

I used to give Google money for services (Drive and YouTube), but I've already stopped doing that because of their evil ways. This just hammers it home that much more.

Edit: The shitty part is what a cool company it used to be. And to watch it destroy itself like this is just sad.

I was a premium subscriber for a long time, and probably still would be if Google hadn't turned so evil that I can no longer in good conscience pay them any money.

But what pushed me over the edge with an ad blocker was a page I got to where every paragraph had a video ad in between. That was it.

Turns out if you get rid of ads and the algorithm, you end up back in the land of sanity.

Louis Rossmann: "when the pirate experience is better than the paid experience, you have a problem."

I haven't tried it, but anything that's interoperable is fine by me.

Maybe I just didn't hit reload enough times. 😅

These piped links just sit on the spinner for me and don't load. Am I missing something?

I would be so much happier with this than relying on a third party like Google to provide access to my passkeys.

It's my understanding that the passkeys are stored encrypted so this is not an issue.

Google deciding to disable your account for no reason is something to fear, though.

I'm guessing conversion of those boosters to electric would be part of the process...? But I don't know.

It is very unlikely there is customer confusion over the matter. Though both companies are in tech, they are in wildly different branches of tech. I don't think X.org has a valid trademark complaint in this case.