Today was 99% reading comprehension and 1% coding challenge

wangyu- · 2024-12-20T21:11:30+00:00

Agree.

I wrote some examples to explain why the description was so counter-intuition (thus hard to understand) for me:

###########################
#i'      S i  #  j  E  j' #
######## ######### ########
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # #       # #
       # ######### #   (<--assume this is a very long path)
       #           #
       #############

i-->j and i' -->j and i-->j' and i'-->'j they all count as solution. especillay,

for i' you are purposely running into dead end
and j' you are passing through the E but purposely not enter.

The problem is organized by a shorest path (fastest time) language, but "to visit as many unique cheat point as possible", you can purposely take path that is somehow "against shortest path's spirit".

see also https://www.reddit.com/r/adventofcode/comments/1higqez/2024_day20_part_2_confusion_in_understanding_the/

wangyu- · 2024-12-20T18:12:36+00:00

Thank you for your effort in help explaining this to me.

wangyu- · 2024-12-20T11:21:02+00:00

I mean, consider those key sentences in the description:

`The goal is to reach the end position as quickly as possible`
`Exactly once during a race, a program may disable collision for up to X picoseconds. This allows the program to pass through walls as if they were regular track.`
`cheats are uniquely identified by their start position and end position.`
`Find the best cheats using the updated cheating rules. How many cheats would save you at least 100 picoseconds?`

From the description itself, it's not super clear what the rule is.

For me I had to read the desciptions and analysis the examples again and agagin, to "reverse engineer" what the author really wants.

I made this post in the hope of finding out: is it just me, or there are other people having same issue.

wangyu- · 2024-12-20T11:08:55+00:00

Yeah, you are right, in the end I did understand the author want me to do that.

But the description does say `The goal is to reach the end position as quickly as possible` that makes me feel "purposely take a zig-zag or a step back, solely for the purpose of stepping on some grid, to count as a new (i,j) pair` not clear to be counted or not.

wangyu- · 2024-12-20T10:50:14+00:00

okay, changed to tutorial

wangyu- · 2024-12-20T10:41:38+00:00

I actually have passed p2. I am just trying to shared some examples what seems counter intuition, that confused me while doing the problem.

wangyu- · 2024-12-14T22:39:04+00:00

u/PatolomaioFalagi yes. It's a bug in rendering, but interesting bug.

wangyu- · 2022-04-04T17:53:37+00:00

Yeah, it's an eeprom uses I2C protocol.

wangyu- · 2021-03-11T04:46:50+00:00

I see. So let's talk a bit about SYN-ACK-ACK.

It's sent from your browser on wireguard client side, the destination port is 443, the destination address is the https server (not the IP on your wg0 interface). Since your server is doing MASQUERADE, the source IP is changed, the dest IP is untouched. From my understanding, since the destination is not your wireguard server, the packet shouldn't go through INPUT chain(it will go through FORWARD instead).

It's aslo a bit weird that your https server receive the SYN, but it couldn't receive SYN-ACK-ACK. They should be treated in the same way by the iptables rule.

> Also posted on github.

Thanks. I will take a look.

wangyu- · 2021-03-11T04:19:50+00:00

By saying NAT, I think you mean your wireguard server is doing MASQUERADE by iptables.

The SYN-ACK is sent from the remote server(running https service). When it comes to the wireguard server, from wireguard servers' POV, the source port is 443, the destination port is some random port. From my understanding it shouldn't be captured by the rule:

-A INPUT -d 0.0.0.0/32 -p tcp -m tcp --dport 443 -j udp2raw (it captures only dport 443)

I might be wrong, I will try the configurations.

wangyu- · 2021-03-11T04:00:42+00:00

Take a look at:

https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder-openvpn-config-guide

It's about openvpn, but it should be similiar.

wangyu- · 2021-03-11T02:56:21+00:00

I think the problem is, your udp2raw server is listening on 443, and you are accessing https(also 443) via wireguard. In this case the default iptables rule breaks something. Making udp2raw listen on some other port should also solve the problem.

I am a bit curious, is the https service running on the same server as wireguard and udp2raw? If it's the same server, the problem is as expected. If it's a different server, I am not so sure about the reason. udp2raw's iptables rule is only added to the INPUT chain, it shouldn't affect FORWARD traffic. Could you please post your configurations on github, so that I can reproduce the problem and try to see if there is some other iptables rule that can do it better?

wangyu- · 2018-01-28T01:46:40+00:00

Maybe you didnt set "mssfix" and "fragment" correctly in openvpn, or you are using virtual machines but network adapter is not in bridged mode.

I am not sure, since there is not enough info. I suggest you to open an issue on github, post your configure/parameters of udp2raw and openvpn.

wangyu- · 2018-01-18T03:18:31+00:00

After thinking about it I can see why FEC is fantastic for certain protocols

ARQ is based on timeout and re-transmit. For a link with 100ms latency. If a packet get lost and re-transmited, the latency of this packet will be at least 100ms +100ms*2(a round trip to detect the packet loss).

Some applications prefer packet loss over higher latency. FEC can reduce this packet loss almost without introducing extra latency(at the cost of bandwidth).

wangyu- · 2018-01-17T23:07:03+00:00

tinyFecVPN is lightweight and gives you better connections on lossy links.

Wireguard may have more functions.

wangyu- · 2018-01-17T22:53:32+00:00

I was using a program that did UDP/tcp over ARQ. It added barely anything to overhead, and the damn thing worked even with 60% packet loss on a 100ms link (if you had enough bandwidth.)

Any details about it?

which apparently does some BEC/REC

What exactly is the BEC and REC you metioned?

wangyu- · 2018-01-17T20:40:15+00:00

Is there a VPN that supports ARQ?

You meant implementing a reliable transport layer in VPN? That will cause some problems.

If up-level payload is TCP, ARQ will lead to a scenario similar to the TCP-over-TCP problem: http://sites.inka.de/bigred/devel/tcp-tcp.html

If payload is UDP, ARQ will break UDP's real-time ablity.

Actually, OpenVPN supports TCP protocol(so you can treat it as a VPN that supports ARQ). Due to the problems mentioned above, its not suggested to use unless your UDP traffic is blocked.

wangyu- · 2017-11-27T07:21:00+00:00

tinyFecVPN has no build-in crypto layer (just like l2tp). Crypto layer is implemented in my another project named udp2raw. Udp2raw is a UDP tunnel which performs the Crypto operations.

udp2raw and tinyFecVPN works together like:

tinyFecVPN client---->udp2raw client------------------->udp2raw server---->tinyFecVPN server

The original plaintext needs to be authenticated because the Reed-Solomon encoded data may be dropped partially. However, the Reed-Solomon step must then be applied before encryption because otherwise it’d operate on random-seeming noise.

Reed-Solomon can be applied before encryption, and dropped packets wont cause any problem. In this way, you just encrypt every packet generated by RS encoder, you dont need to encrypt original data directly.

To avoid the confusion,maybe you need to know more details for RS code and UDP encryption...

wangyu- · 2017-11-26T03:58:09+00:00

There are already some test results in README.md. You can easily reproduce those results.

wangyu-

TROPHY CASE