> Some routers and firewall silently kill idle TCP connections without telling application. Some code (like HTTP client libraries, database clients) keep a pool of TCP connections for reuse, which can be silently invalidated. To solve it you can configure system TCP keepalive. For HTTP you can use Connection: keep-alive Keep-Alive: timeout=30, max=1000 header.
Once a TCP connection has been established there is no state on routers in between the 2 ends of the connection. The issue here is firewalls / NAT entries timing out. And indeed, no RSTs are sent.
We had the issue in K8s with the conntrack module set too low.
Note that TCP Keep-Alive might not play well with mobile devices.
Mobile operating systems can use application-level keep-alive packets, because those can be easily attributed to individual applications: an applications receives a TCP/UDP packet during low-power CPU sleep mode, asks system to wake up (by e.g. taking a wake-lock), and the system takes note who caused the wake-up. TCP Keep-Alive happens below application level, so it may be disabled, even when application can still be reached.
> A method that returns Optional<T> may return null.
projects that do this drive me bananas
If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it
public interface Alpha {}
@java.lang.NonNullReference
public interface Beta {}
Alpha a = null; // ok
Beta b = null; // compiler error
javac will tolerate this
Beta b;
if (Random.randBoolean()) {
b = getBeta();
} else {
b = newBeta();
}
but I would need to squint at the language specification to see if dead code elimination is a nicety or a formality
Beta b;
if (true) {
b = getBeta();
} else {
b = null; // I believe this will be elided and thus technically legal
}
I question the wisdom of even having Optional<T> in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.
It works quite well in Scala, which still tolerates nulls due to being in the JVM and having Java interop. Realistically nothing in the language is going to return null, so the only time you might have to care is when you call Java classes, and all of the Java standard library comes scalaified into having no nulls. And yes, there are enough monadic behavior in the standard library to make Option and Either quite useful, instead of just sum types.
Java really suffers with optional because the language has such love for backwards compatibility that it's extremely unlikely that nulls would even be removed from the standard library in the first place. The fact that the ecosystem relies on ugly auto wiring hacks instead of mandating explicit constructors doesn't help either.
Maybe this is cute monady stuff, but there isn't an equivalent to Optional<Optional<T>> with only null/None. You usually don't directly write that, but you might incidentally instantiate that type when composing generic code, or a container/function won't allow nulls.
There's a lot of quality-of-life stuff enabled by it in Java, since the base language's equivalents to Optional.empty(), Optional.ofNullable(...).orElse(...), etc are painfully verbose by comparison.
You're far from alone, it does make it a tiny bit easier to see which functions are expected to return null, but that's about it and messing around with it always feels like wasted effort.
Yeah, sure, and thankfully everyone has already switched all their teams to superior languages
Anyway, I believe what you're referring to is the "?" syntax that annotates types in Kotlin but doesn't help the resulting bytecode, which means that every single library ever would need to convert to kotlin to benefit
fun doit() : java.io.InputStream? { return null }
kotlinc test.kt
javap -c test.class
public final java.io.InputStream doit();
Code:
0: aconst_null
1: areturn
So even they didn't have the courtesy of marking the result of a known Optional result as Optional<java.io.InputStream> when interfacing with the existing Java ecosystem
> Java, C# and JS use UTF-16-like encoding for in-memory string
That’s incorrect for Java, possibly also for C# and JS.
In any language where strings are opaque enough types [1], the in-memory representation is an implementation detail. Java has been such a language since release 9 (https://openjdk.org/jeps/254)
[1] The ‘enough’ is because some languages have fully opaque types, but specify efficiency of some operations and through it, effectively proscribe implementation details. Having a foreign function interface also often means implementation details cannot be changed because doing that would break backwards compatibility.
> JS use floating point for all numbers. The max accurate integer is 2⁵³−1
That is incorrect. Much larger integers can be represented exactly, for example 2¹⁰⁰.
What is true is that 2⁵³−1 is the largest integer n such that n-1, n, and n+1 can be represented exactly in an IEEE double. That, in turn, means n == n-1 and n == n+1 both will evaluate to false, as expected in ‘normal’ arithmetic.
The representation for C# is very much fixed, as it allows, and very commonly uses, direct access into the string buffer as a ReadOnlySpan<char> or a raw char pointer, where char is the type of UTF-16 codepoints.
I started to say something about C# strings and then I remembered the clusterfuck when it came to Windows development and strings and depending on which API you call, a string is represented by one of a dozen different ways.
> > Java, C# and JS use UTF-16-like encoding for in-memory string
>
> That’s incorrect for Java,
Maybe so, technically, but if you Base64 encode a string in a language that uses UTF-8 (or another UTF-16 with another endian) and decode it in Java, Java's UTF-16 representation will be the problem you will be dealing with.
That's a nice compendium of tips and useful information.
I wonder if anyone can learn from this. I feel like I only understood what I already knew, or at least was very close to knowing. That's the same thing that happens with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topics, but often very bad at teaching the same topics to an audience that doesn't know anything.
> with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topic
I think that the reason for a manual existence. To have a written record so we don't have to trust our memory. This is what most unix manuals are. You already know what the software can do, you just need to remember the specificity on how to get something done.
> often very bad at teaching the same topics to an audience that doesn't know anything.
What you need then is a tutorial (beginner seeking to learn) or a guide (beginner/intermediate seeking to do). Manuals in this case only serve to have better questions (Now you know what you don't know).
For what it's worth, I really enjoyed "Traceroute Isn't Real." I have noticed for quite a while that the data from it is at best patchy, often apparently meaningless. So it's helpful to see the explanation of why that is expected behavior:
I'm not regularly a python developer and I just spent a ton of time earlier this week tripped up by the default argument being a stored value. I was using to make an empty set if no set was passed in... but the set was not always empty because it was being reused. Took me forever to figure out what was going on.
I guess the first trap should really be: "You cannot read any CSS property in isolation, as just like what the name implies, defaults and what values end up doing cascades through all the rules your document ends up using"
CSS cascade for text properties more or less makes sense.
I have been unable to comprehend CSS layout from any perspective: page designer, implementer, user, anything. It must have someone in mind but I have no idea who I that is.
https://every-layout.dev has by far the best explanations and coherent usage of CSS I've encountered since I started doing webdev for a living in 1998.
Readit News
Once a TCP connection has been established there is no state on routers in between the 2 ends of the connection. The issue here is firewalls / NAT entries timing out. And indeed, no RSTs are sent.
We had the issue in K8s with the conntrack module set too low.
Now, you can try to put in an HTTP Keep-Alive, but that will not help you. The HTTP Keep-Alive is merely for connection re-use at the HTTP level, i.e. it doesn't close the connection: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
An HTTP Keep-Alive does not generate any packages, it merely postpones the close.
A TCP Keep-Alive generates packages which resets the timers.
Mobile operating systems can use application-level keep-alive packets, because those can be easily attributed to individual applications: an applications receives a TCP/UDP packet during low-power CPU sleep mode, asks system to wake up (by e.g. taking a wake-lock), and the system takes note who caused the wake-up. TCP Keep-Alive happens below application level, so it may be disabled, even when application can still be reached.
projects that do this drive me bananas
If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it
javac will tolerate this but I would need to squint at the language specification to see if dead code elimination is a nicety or a formalityJava really suffers with optional because the language has such love for backwards compatibility that it's extremely unlikely that nulls would even be removed from the standard library in the first place. The fact that the ecosystem relies on ugly auto wiring hacks instead of mandating explicit constructors doesn't help either.
Dead Comment
Anyway, I believe what you're referring to is the "?" syntax that annotates types in Kotlin but doesn't help the resulting bytecode, which means that every single library ever would need to convert to kotlin to benefit
So even they didn't have the courtesy of marking the result of a known Optional result as Optional<java.io.InputStream> when interfacing with the existing Java ecosystemThat’s incorrect for Java, possibly also for C# and JS.
In any language where strings are opaque enough types [1], the in-memory representation is an implementation detail. Java has been such a language since release 9 (https://openjdk.org/jeps/254)
[1] The ‘enough’ is because some languages have fully opaque types, but specify efficiency of some operations and through it, effectively proscribe implementation details. Having a foreign function interface also often means implementation details cannot be changed because doing that would break backwards compatibility.
> JS use floating point for all numbers. The max accurate integer is 2⁵³−1
That is incorrect. Much larger integers can be represented exactly, for example 2¹⁰⁰.
What is true is that 2⁵³−1 is the largest integer n such that n-1, n, and n+1 can be represented exactly in an IEEE double. That, in turn, means n == n-1 and n == n+1 both will evaluate to false, as expected in ‘normal’ arithmetic.
The representation for C# is very much fixed, as it allows, and very commonly uses, direct access into the string buffer as a ReadOnlySpan<char> or a raw char pointer, where char is the type of UTF-16 codepoints.
JS could maybe get away with it.
I think Java moved away from this back around 8, or possibly 9.
https://stackoverflow.com/questions/689211/interop-sending-s...
>
> That’s incorrect for Java,
Maybe so, technically, but if you Base64 encode a string in a language that uses UTF-8 (or another UTF-16 with another endian) and decode it in Java, Java's UTF-16 representation will be the problem you will be dealing with.
Deleted Comment
I wonder if anyone can learn from this. I feel like I only understood what I already knew, or at least was very close to knowing. That's the same thing that happens with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topics, but often very bad at teaching the same topics to an audience that doesn't know anything.
I think that the reason for a manual existence. To have a written record so we don't have to trust our memory. This is what most unix manuals are. You already know what the software can do, you just need to remember the specificity on how to get something done.
> often very bad at teaching the same topics to an audience that doesn't know anything.
What you need then is a tutorial (beginner seeking to learn) or a guide (beginner/intermediate seeking to do). Manuals in this case only serve to have better questions (Now you know what you don't know).
When I was a kid I was trying to learn Linux and commands and it was disappointing.
Over the years of using it I don’t need to learn it but I do need to look stuff up.
Much of it would only apply in certain relatively narrow contexts, but the contexts aren't necessarily mentioned.
Some of it appears to be just wrong.
I guess I'm saying: I would not take this literally, but as something almost like a stream-of-consciousness.
https://gekk.info/articles/traceroute.htm
(If it's outdated I'm curious if anyone knows relevant updates?)
PSA for anyone working with datetime variables!
From MDN: "For block boxes, inline boxes, inline blocks, and all table layout boxes auto resolves to 0."
https://developer.mozilla.org/en-US/docs/Web/CSS/min-width
I have been unable to comprehend CSS layout from any perspective: page designer, implementer, user, anything. It must have someone in mind but I have no idea who I that is.
Deleted Comment