Previous thread: >>100081771Performance is improved a bit by binding to one core. Might add QOI image compression later.Runping -c 1 2a01:4f8:1c1e:85cd:XXXX:YYYY:RRGG:BBAAto draw a pixel on the canvas. View the canvas here:https://canvas.zipdox.net
ping -c 1 2a01:4f8:1c1e:85cd:XXXX:YYYY:RRGG:BBAA
we are so back :3>>100127611can you upload a full screenshot of the first canvas?
>>100125302>Use WebRTC (UDP-like) instead of WebSockets (TCP-like) for streaming tile pixel deltas, should improve things a lotWebRTC is significantly more complicated and would introduce more failure modes. I think threading is a better course of action.>Multithread/multiprocess ICMP receives and image writes to the mmap'd buffer, pin each of these to their own coreI think putting the ICMP reception on its own thread is the next step. Communicating the draw calls from one thread to the other to update the users is already difficult enough, having multiple threads seems too difficult.>Use a separate thread/process to handle web clients (maybe multi-threaded, not sure how that would work exactly, SO_REUSEPORT can do this apparently), pin this to its own coreSee the above.>Don't do alpha blendingAlpha blending is already omitted if alpha is 0xFF, and people rarely even draw transparent images. >Disable ICMP replies in the kernel, reply to ICMP packets manually and buffer replies during ping_cbI'm hesitant about disabling ICMP replies since "pinging to draw" is the whole appeal of the site. As for manually replying, I tried that before and it came with some problems. You cannot use a regular ICMPv6 RAW socket to reply, as the kernel will pick the source address (it needs to be the one you received it on), and using a raw IPv6 socket requires manually creating the entire packet with checksum and everything. I tried that, I couldn't figure the checksum out.
>>100125302>Remove the blocklist, if you want to block people do it in iptables with the PREROUTING table, much more efficientWill this work. I tried UFW before and it didn't work since the RAW socket receives everything anyway.>Make tiles client driven for re-fetch and re-fetch periodically (required due to UDP loss): clients request tiles with a timestamp, the server compares said timestamp to the timestamp stored for that tile (separate mmap'd file, uint32 per tile to store last modified timestamp), if older than current send the tile, otherwise send nothingThis would not give the user experience I want from the site. Getting real-time updates is a big appeal of the site.>Use ICMP packet data payload for less overhead: e.g. IP just specifies where to start drawing from and first pixel color, then the bytes in the ICMP packet are interpreted as RGB values for adjacent pixels (e.g. x+1, x+2, x+3, etc.), can still allow the simple ping API by using the code field in the ICMP packet (should always be 0 for ping, but can be changed for people generating custom ICMP packets) since some ping programs fill the data payload with random dataDefeats the whole gimmick of abusing the IPv6 address space. You seem to have forgotten the purpose of the project.
>>100127611Good morning sirs.Also the doesn't work.>>100127758I really want WebRTC. I want higher refresh rate bad apple.Maybe I'll see if I can hack a pull request together myself later today.
So it's all just nekoarc past a point
https://canvas.zipdox.net/: Name or service not known??
>>100127611allow zoom 0.1 you GAYLORD
>>100128080>2hu hijackerare you the spammer faggot?>>100128080>https://canvas.zipdox.net/: Name or service not known>??kek basedeat shit spammer
>>100127611the glownigger assigned to logging the draws and 80 billion ip packets
>>100127758>WebRTC is significantly more complicated and would introduce more failure modes. I think threading is a better course of action.NTA, but what about QUIC? I have no idea how it works under the hood, but it sounds like a potential UDP-based option.>As for manually replying, I tried that before and it came with some problems. You cannot use a regular ICMPv6 RAW socket to reply, as the kernel will pick the source address (it needs to be the one you received it on), and using a raw IPv6 socket requires manually creating the entire packet with checksum and everything. I tried that, I couldn't figure the checksum out.So the kernel won't let you send an echo reply without getting a request from that address first? Getting this working would probably significantly reduce the amount of ICMP traffic, since painters could actually confirm that their pixel got applied.
>>100128637Yes but filling the canvas with touhou hijack lol got boring so I started running high-res bad apple at 0,0
OP you okay? All I'm getting is argo tunnel and cloudflare gateway errors
>>100129440same
>>100127611idk if your doing this already but if you can get 2 interfaces on your vps bind web to 1 and icmp to the other. it would still let you ssh if someone is drawing with a full ddos too
>>100127758>WebRTC vs WebSocketsThe problem is the kernel has to buffer all the WS data you're trying to send, and because the NIC is so clogged up it's throttling. I'm not familiar with the details of WebRTC vs WebSockets, but using UDP makes much more sense for this data than TCP>Separate ICMP thread, synchronization to WS thread for updatesI think you're going to run into synchronization bottlenecks if you do that, probably need to try to see however>Alpha blendingIt's pointless because the packet delivery is unreliable, so you have to re-send pings and because the ping replies are also unreliable you just have to send pixels multiple times, which fucks up the color if you want one layer of alpha blending. If ping replies become reliable it makes more sense, but currently it's pointless. The main reason to do this is to enable multiple ICMP threads to blindly write to the buffer without coherency concerns, otherwise the image can look different depending on what each thread sees at a particular pixel.>Disable ICMP replies, send manuallyI agree, but the fact that the replies are kind of useless (currently) is why I'm suggesting this. I have working code to send IPv6 packets containing ICMPv6 packets that I can post. Replying correctly requires sending basically the same packet received with some fields modified but keeping the data payload intact and recomputing the checksum. You can use an ICMPv6 socket, but you need IPV6_HDRINCL sockopt>Remove blocklistI'm actually not sure, probably needs testing. It seems like PF_PACKET does bypass iptables/netfilter, but I'm not sure if AF_INET6 sockets do (I would think not since it's IP level). Another option is to use your VPS's firewall rules to do this which should work regardless. See this link for iptables raw filteringhttps://unix.stackexchange.com/questions/243079/netfilter-iptables-why-not-using-the-raw-table/244527#244527>Real time updatesCan still be done via WebRTC or more frequent tile requests
>Finaly acquire le VPS>Site downmfw
>>100127768>ICMP payload for sequential pixel accessIt's just a more efficient API to deliver data. If you don't want to do it I understand, but you're still using the IP space for communicating location and color data and it would still work for naive clients, it's just a more efficient way to use a single packet. It's similar to how sequential writes work for most serial interfaces (SPI, DDR, etc.)I've been enjoying this project OP, I just want to see what can be achieved with enough optimization. Being able to stream bad apple via ICMP is cool.2 other things that would probably help that have been previously suggested:>Send tiles compressed (gzip or some shit, not familiar enough with web to know what the options are)>Use separate NICs for ICMP and web traffic like >>100129500 suggests2nd one would probably require talking to support to get a 2nd NIC added I imagine, since I don't see anyway to do that on Hetzner's website (probably more complicated than that if you're on a dedicated host and not a vCPU)
>>100128932CF already does QUIC.
what about throwing away this whole shitty web client and force people to write their own, that way you can do shit like replying through udp without dealing with QUIC and slowing shit up with encryption
>>100130171>Send tiles compressed (gzip or some shit, not familiar enough with web to know what the options are)Fairly sure CF already uses compression (I even enabled brotli).>Use separate NICs for ICMP and web traffic like >>100129500 suggestsI don't think I have much choice with a VPS.
Fixed it and added 2 optimizations ive been bugging op with, also turns out whatever code got changed broke binding to 0.0.0.0, i actually have to bind to the real ip now for websockets to work.http://canvas.senko-san.com2a01:4f8:a0:312c:xxxx:yyyy:RRGG:BBAA>>100130234You could still hit bandwidth limits from your server to cloudflare. One idea I had would be some kind of websocket proxy that would take a single connection from the canvas server and relay that to seperate servers that could handle just the web clients.
>>100130234>CFInteresting, I'm not really familiar with much web tech. I'm not sure what this buys you exactly, e.g. are you still sending the same amount of data via WS, but to CF instead of us directly, or are you actually sending less? I guess there might be caching benefits or something? Compressing on the server would have the benefit of sending less data in the first place. I think you will still get clogged up trying to send data to CF unless you configure the kernel to prioritize TCP traffic much more than ICMP (if that is possible), and either separate the ICMP/WS threads or change the loop in ping_cb like I was talking about in the MR, since it probably spends a disproportionate amount of time handling ICMP data compared to WS data.
ping_cb
>>100130361What optimizations?
>>100130473don't send ping replies, don't send browser update if a pixel was changed to the same color it already was, and compiled with -march=native which I don't believe op does. I think some other browser updating code is slightly broken though, I don't know enough C++ to touch much more code.
Looking at how the tiles are sent I may be able to compress and cache tiles through my apache server, could make the browser experience smoother.
>>100130361this one works a lot better
Huuh, you gotta throttle your pings very granularity, at a millisecond-level, otherwise you get tons of loss even if the overall PPS is the same. Even throttling every 2ms seems to perform way worse than 1ms.
>>100131159Don't throttle based on time, throttle based on number of packets, and use a spinsleep for finer granularity. You especially want to make sure you don't fill up the socket's send buffer. Determining loss on the other side isn't possible without responses however, so if the network conditions change at the server you would have to manually adjust the throttle or send duplicates preemptively to increase your delivery rate.
>>100131205I am doing that I think. If I send more than ppms_target, I sleep until the current time window is over.>Determining lossI just look at the canvas, how many pixels fail to update with bad apple. I did yesterday write a complex ass ping chunking system only to discover echo has zero correlation with what gets drawn on canvas. http://canvas.senko-san.comI'm currently sending only 1 update per pixel. 20-100kpps depending how much there is to update. I see no loss at all except sometimes when sustaining 100kpps for few seconds.Now once OP's server gets back online, it wont work this cleanly. But even on senko's canvas, throttling in 2ms windows lead to ton of loss. Now the challenge here is finding the most important pixels to (re)send in under a millisecond. Naive optimal algos don't perform well enough, and I'm on a ryzen 5800x and writing this with C, on a VPS it'll be even more difficult. This silly canvas became a real-time video encoding problem.
>>100131494im seeing about 20-70% cpu over the last few minutes on a single core from the canvas. I have apache proxy, caching, and compression working except I can not figure out whats wrong with websockets, I cant get it to work at all so no auto updates. im working on that one at just senko-san.com
Multi threading seems to speed up painting by some degree in my case (increasing from 4 threads to 10 reduced painting time by more than 50%).I noticed that drops happened around same columns, is there a reason for that?
>>100131494Interesting, I need to implement a noack/throttle mode and a random pixel ordering mode still. So are you receiving the canvas in your pinger to determine loss or adjusting manually by looking at the canvas? I'm going to make a PR for OP's repo to manually send ICMP responses so that they are a reliable indication of a canvas write.>Most important pixels to sendIf you don't know which ones are received or not then probably the ones with the largest delta. Doing that optimally requires sorting which is probably out of the question (maybe? idk if something like optimized radix sort could do it), but you could have a few different delta thresholds and run through the image in threshold order, sending largest changes first, a lower threshold range, etc.
>>100127611>gayflare access denies>gayID: ...it's over
>>100131568fixed websocket proxy but since all data is sent through it the cache and compression don't work. It might work to ping the browser with websockets and grab all the updated tiles over http, Won't have that done for a bit especially since im stuck using a laptop, there is construction going on in my office.>>100131690I originally built a multi-process python script that would only do 200k pps and took forever to load the image in. No I use that python script to "compile" a pcap file and just replay it with tcpreplay
>>100131867I've did sth in rust but no matter what I do I can't seem to speed it up further. Guess I'm just limited by VPS
>>100131736Just manually. I don't really care to get perfect results, I think it's a lot more interesting when you can see the optimizations and interesting artifacts and patterns other people's spam and packet loss creates. And the point across gets across the best when the packets are prioritized on motion instead of cleaning up blank areas. >Doing that optimally requires sorting which is probably out of the question ...With the 360x270 resolution I'm using right now, that's about 100k items to check for changes and sort, every 1ms. I don't like those numbers either. Yesterday I just looped through the image in a predetermined random order. If there's a change, I send it, if not, RNG, less and less likely to be re-sent the more time it's already been sent. Sometimes this created decaying trails reminiscent of CRT phosphors.
>>100132063Though I suppose you could do the checking and sorting only when the frame changes, though I suspect that makes scheduling the sends unnecessarily complicated. My current approach eliminates digital looking artifacts, very pleasantly noised in and out. Want to keep that. But to achieve that you have to randomize both space and time ..
ok that's neat
added grafana dashboard for my canvas and upped the refresh rate to 4fpshttps://grafana.lilprincess.xyz/d/cdjix8a0xdybkb/hetzner01?orgId=1&from=now-15m&to=now>>100132018tcpreplay was hitting just over 600k pps, not sure how many hit ops server but when I briefly did that the whole site would freeze, the sweetspot for pps to missing packets was just under 100k pps
Nice 502 you worthless NIGGER
>>100132954600k pps seems to be the limit of the sockets. 100k saturates approx 100mbps upload.Anyone know how to go past 600k pps on a single socket? SO_SNDBUFFORCE doesn't help, even if the value is set and confirmed by getsockopt.Two sockets necessary to saturate a gigabit link?>>100133021You can use http://canvas.senko-san.com/ while OP is asleep.
>>100133343Two sockets necessary to saturate a gigabit link?Doesn't work ): they share buffer I guess
>>100133343100k icmp packets/s is only ~4.5 MB/s600k icmp packets/s is ~27.5 MB/sthe issue you're running into is how fast the OS + NIC can take packets out of the buffer and put them on the wire. To go faster you can try to use an AF_PACKET socket and write Ethernet frames directly. Also see this CF post, it's for receives but generally applies to transmits as well:https://blog.cloudflare.com/how-to-receive-a-million-packetsCheck out the ethtool stuff in that post and core pinning
>>100133487>100k icmp packets/s is only ~4.5 MB/sMy network counters show ~8MiB/s though>the issue you're running into is how fast the OS + NIC can take packets out of the buffer and put them on the wire. o go faster you can try to use an AF_PACKET socket and write Ethernet frames directly. Ok I'll try this
>>10013352940 bytes for IPv6 header 8 bytes for ICMP header = 48 bytes per packet, 100k * 48 = 4.8 MB or 4.5 MiB
>>100133564struct icmp from netinet/ip_icmp.h is 28 bytes, which then gets the 40 byte header added to it.Am I doing something wrong?Guess I need to read how this shit actually works. Copying shit blindly is great at getting stuff working fast but it creates knowledge debt ...
>>100133758You can send just the icmphdr struct, which is 8 bytes. The Wikipedia page for ICMPv6 and IPv6 are both pretty good. The only tricky thing imo was computing checksum manually, since "one's complement sum" is not something most people are familiar with. I studied EE and we only ever briefly talked about 1's complement arithmetic since basically everything uses 2's complement.
>>100133821Ok I got it to work, but my network counters show exactly 6MB/s at 100kpps, not the 4.5, and 100kpps is still the cutoff for significant loss ..
>>100134006You're on your home network? It might be that your router can't handle more packets/s, especially since reducing the bandwidth didn't affect it. Check if you're dropping packets on your machine with ethtool, if not then it's probably your router or something upstream.
>>100134050My computer is the router. There's nothing between me and the WAN, not even a modem. Nothing seems to be dropping on my NIC.
>>100134162I'm not sure then, it could be something upstream from you managed by your ISP.
>>100134188I seem to be able to get more than 100k through by running two processes, but not 100% sure. I'll see if using sendmsg over sendto etc optimizations will help.
>>100131867>>100133343Finally have my office back and can focus on this. I would prefer everyone use https://senko-san.com to view the canvas, this should offer gzip and caching on first tile loads and possible routing improvments for people in America, the rest is still out of my control on websockets until I can figure out how to optimize that. http://canvas.senko-san.com is direct connection to the canvas server in Germany with none of thoese optimizations.
>>100134674Put the IPv6 range in the server info
I got filtered by sendmmsg()
>>100134674Also gzip definitely helps a ton with exploring the canvas, but I'm having weird issues where nothing will load in some areas. I went out to like 20000,20000 and drew some stuff but then it froze and hard refreshing doesn't seem to bring it back
>>100134852info should be up now2a01:4f8:a0:312c:xxxx:yyyy:RRGG:BBAA>>100135205cache wasn't expiring, changed some settings, should be fixed now. May have to do it server side as well as the proxy is doing ~50MB/s download and only ~2MB/s upload after gzip
Whoever the other bad apple guy is, the screen tearing is cool consider it looks complete. Are you determining which frame to sample per pixel?
I see you are using debian
>>100135301Yeah gzip server-side speeds it up alot>>100135430Debian for servers, Arch for desktop, Windows at work.
>>100135391Me at 0,0? Yeah the rate-limited scanning is completely independent of the video framerate. I disabled the index shuffling there for a moment, which made the tearing behavior obvious. That flandre transition is cool
>>100135596Nice. Because of how mine works I can't do inter-frame sampling, I have to just frameskip an entire frame. Next thing I want to implement is some kind of preemptive duplication for pixels with large delta between frames, some kind of probabilistic duplication when sending the pixel, problem is sending the original and the duplicate after each other is not ideal, probably need a 2nd pass or something once I finish sending the frame to send out the duplicates. I should probably implement the low but non-zero probability of sending pixels that didn't change as well like you mentioned previously.
Seems it got killed by the OOM killer. Seems there's a memory leak somewhere.
>>100135856pls up the updates to 4fps, senko's canvas looked so good with it
Is there a way to download specific areas without any scaling?
I was looking at this thing yesterda and it killed a browser tab lmao
>>100137501#!/bin/bashmkdir -p tilesfor y in {0..255}do for x in {0..255}; do curl "$1/tile/$x/$y" -o tiles/$x,$y donedone
#!/bin/bashmkdir -p tilesfor y in {0..255}do for x in {0..255}; do curl "$1/tile/$x/$y" -o tiles/$x,$y donedone
Working on manually replying to ICMP requests.
Who going to exfiltrate some corpos database via icmp, without icmp payloads.
ping -c 1 2a01:4f8:1c1e:85cd:1:1:1:1Pinging 2a01:4f8:1c1e:85cd:1:1:1:1 with 32 bytes of data:PING: transmit failed. General failure.PING: transmit failed. General failure.PING: transmit failed. General failure.PING: transmit failed. General failure.ping -c 1 2a01:4f8:1c1e:85cd:1111:1111:fffa:fffa -t -l 0 -6Pinging 2a01:4f8:1c1e:85cd:1111:1111:fffa:fffa with 0 bytes of data:PING: transmit failed. General failure.PING: transmit failed. General failure.PING: transmit failed. General failure.PING: transmit failed. General failure.PING: transmit failed. General failure.I fail at life -_-'Cant even make ping work
Finally learning git https://gitlab.com/senko_san/ipv6-canvasI added tile modified headers so the tiles can be cached and compressed by webservers and lowered delay so it should be 8 fps now. Currently testing on 2 servers(New York Proxy) https://senko-san.com/(Germany Proxy and canvas server) https://canvas.senko-san.com/2a01:4f8:a0:312c:xxxx:yyyy:RRGG:BBAA(Grafana stats) https://grafana.lilprincess.xyz/d/cdjix8a0xdybkb/hetzner01?orgId=1
>>100140074Nice, 8 fps feels way better for video. Your repo isn't public though, I can't access that URL.>>100138104I put in a PR for manually sending ICMP replies, which should make the response a reliable indicator of a write and reduce the need to spam the server with packets.
>>100140074Is there a packets/s graph in Grafana? Also what's up with incoming Mbps being negative? I can see your repo now though, yeah not sending pixels if they didn't change is a good idea, you should make a PR for it.
Bump
Dead canvas
>>100134162>>100134188Oh also, I randomly remember this post of mine >>100131159Reducing the throttling window to 100 microseconds lets me saturate my upload bandwidth, reaching 180kpps sustained with no loss (on senko's canvas). Now, 180kpps shouldn't take the 12MB/s my network counters report (it should be 8.6MB/s), so there's still some sort of bug somewhere. But not even 1ms throttling granularity is good enough?? Is the internet really this sensitive to bursts? Though I guess I indeed have zero buffering between me and the ISP .. I have datacenter-tier latencies with my home internet :3
>>100143489your dedication to spam and bad apple is admirable
>>100143489So apparently the minimum size of an ethernet frame is 64 bytes. This matches exactly with what I see with my network counters, 64*100k=6.4MB/s. So at least with using raw sockets and sendto(), this is as good as we can get.I know nothing about network shit this deep. Can you do something silly like sending 1 and a half IPv6 ICMP packets in a single ethernet frame, and rest in the next frame? Though even if you could do this, this will greatly amplify loss, if there's any. So probably a bad idea. >>100143989it's fun cuz im leaaaarningBut the guy who bought 10 dedicated servers to lock down 0,0 with a massive fox is arguably more dedicated
>>100144215Oh except ethernet frames can be variable size. We can make it fit, but can you actually send two pings in one frame??
>>100140109>>100140379incoming (download) is negative so the graph points down, packet graph is added, repo is public now, and it looks like there may be cache issues proxy side, probably because im using apache2 to do it, it looks like its just missing and sometimes not compressing so it at least sends fresh tiles.
>>100143489I'm measuring the total time elapsed since the program started (in milliseconds) and dividing the total number of packets sent by time elapsed before each send operation. If that number exceeds max packets/ms then I skip sending (no sleep, just goto over the send code). I can get pretty exact pps targets this way, might be better than trying to do it in a window.>>100144324For some reason I was under the impression that you could send multiple IP packets in a single Ethernet frame, but I guess not after searching a bit.
prev >>100135596 at @80kppsThis is at 288k pps/150mbits, throttled in 50µs resolution. With this config I can exceed my 100mbps upload momentarily, making inverts quite fast. I can do worst-case full-frame 370x260 transitions in 337ms without any loss !!! But if I sustain it, like before Yuyuko, then there's a ton of loss. Fairly sure this is about as optimal as is possible with my connection. The next step is to get a gigabit VPS :D Maybe if OP makes his canvas usable again. >>100145699I sleep and increment ppms_next by 50 whenever utime() is more than it. Basically the same thing. Very exact results.
>>100145819>I sleepNo I don't, I'm being a retard, I sleep until ppms_next only if I reach ppms_target
>>100145819my fork is nearly identical I think its unusable from fox spamming his massive image, I've been spamming my rent free banner at 40k pps from a single server and getting about 20k-30k replies back. I'm working on more efficient tile sending so I can hopefully use http caching and compression more effectively without actually writing that server side, unless I can figure out threading then the server may be fast enough to handle it on its own.I also fully ripped out the blocklist and will update my server with it soon.
Apparently hetzner can add a dual NIC to a dedicated serverhttps://docs.hetzner.com/robot/dedicated-server/general-information/root-server-hardware/but you can't get a 2nd uplink on that NIC?https://www.reddit.com/r/hetzner/comments/e8s0ra/comment/fdmoa5m/I'm not sure I understand what the point is unless it's for local connections only or something
I'm looking into WebRTC to see how it could work. Probably need to build some test programs to mess with first. Other option is to work on multithreading but I think if you're trying to update a buffer every time a pixel changes you're going to have a lot of lock contention between the writer threads and the WS thread.
>>100147999webrtc and webtransport (http3) are a bad idea because these protocols are hard to implement if you want to keep the server code simpleif the issue was that OP is too retarded to implement icmp ping replies in code and that the kernel doesn't reliably send them when overloaded, then experiment with just disabling or keeping ping replies but explicitly sending a udp packet instead of blocking the server on websockets
>>100148216I implemented ping replies in code here: https://gitlab.com/zipdox/ipv6-canvas/-/merge_requests/4The problem is that the NIC is saturated with ICMP packets and the pixel updates are streamed to each client over websockets (TCP), so when the NIC is saturated all the pixel updates get backed up. I'm not a web programmer, but apparently WebRTC uses UDP and should be more suited to real-time streaming of pixel data. There are libraries for this for WebRTC ( https://libdatachannel.org/ ), OP is using libsoup for WebSockets.
Seems nice but how do you prevent DDOS? You should set up a custom ICMP protocol integrating a POW token like a normal person.
what a boring canvas
>>100149899It was a lot more interesting before the touhou retard overwrote everything. I might roll it back. I have a copy from I think 2 days ago.
>>100149899KEK my fucking neco arcs
>>100149899should start in the center desui think it would encourage spreading out, the hash coordinates helped a little
>>100150185or allow zooming out and traversing the canvas more easily
I'm crafting my own IPv6 packets now, maximum pps I can achieve on my system is 1200k before the dreaded Errno 105 limits me. That's double from the 600k it was when I let the kernel do the IPv6 headers for me!!! I *could* use 600Mbps if I had such a connection. But I wouldn't be able to utilize a gigabit vps fully yet. WE NEED TO GO DEEPER>>100150109touhou hijack lolNo the fox killed it. Nobody has drawn anything over my hijack for two days.>>100150185This. Or just randomize the location. Anything but 0,0 as it is now. Make the coords signed!!
>comment out a printf() that doesn't ever even get called>code stops working
>>100146107Server is down :(
>>100151952I ddosed myself writing to op's canvas, might be migrating to something that isnt the cheapest server soon
>>100151748It's one of these bugs that only happen in -O2My packet checksum becomes incorrect if I remove a printf that never gets called.How the fuck do I even debug this??
>>100152116It's probably strict aliasing, try putting -fno-strict-aliasing and see if it fixes it with -O2
>>100152131What the fuck that actually fixed it.I already hated aliasing, now I hate it even more. The fuck does that flag even do??
>>100152099You probably have some not-legal type punning (into uint16_t/unsigned short*?) that makes the compiler assume that 2 incompatible pointers (say a packet header* and a uint16_t*) can't overlap, and performs some optimization that isn't legal if they were to overlap. Basically, only casts (and then access) from T* -> void* -> T* or from T* -> char*, or T* -> void* -> char* are "legal", with some nuance around malloc etc.
>>100152171>>100152203Wrong reply
>>100152203I was sending my pseudo-packet struct as void* to my checksum function, which takes char*. So &struct->void*->char*. And then the checksum function casts that char* to uint16_t* in one spot. The resulting 16-bit checksum's last byte ended up becoming incorrect, but only if a certain printf didn't exist.Casting the struct to a char* instead of void* makes it work regardless if the completely irrelevant printf was there or not.Thanks a lot tho.
>>100152418The cast to uint16_t* is probably illegal, try not casting and reconstructing the uint16_t aschar* data;uint16_t word = ((uint16_t)data[i] << 8) | data[i + 1];
char* data;uint16_t word = ((uint16_t)data[i] << 8) | data[i + 1];
>>100152570Ok this is indeed the most smelly thing I've seen in a while. I copied the checksum function of somewhere. Don't reinvent the wheel, they said. sum += buf[0];sum += buf[1] << 8;*actually* fixes it
sum += buf[0];sum += buf[1] << 8;
>>100152622I need to sleep I fixed it in a very retarded way
holly
>>100140074Last update for my site todayI think I have the apache config worked out for caching, should work on both proxiescan load from 0/0 to 54/30 with 1700 requests 300MB only 25 after compressionI added a fetch queue to the initial tile loading which slows tile loading but lightens server and browser usage
Why even live?
>forget setting some variable as mutable>library works around with some copy-overwrite bullshit instead of screeching autistically>making mutable reduces call time from 100000 nanos to 10 (ten) nanosecondsmaybe I need the handholding after all
>>100153833Might be worth trying the branch I have here for reliable ICMP replies:https://gitlab.com/necospammer/ipv6-canvas/-/tree/manual_icmp_repliesI can look into making a patch for your repo tomorrow since you've got some changes on-top of master
Sending duplicates of pixels with large change between frames didn't help as much as I hoped it would.
>>100127611>Still broken for phone fags>I got doxxed and ip logged for thisREEE OP FIX YOUR SHIT I WANT MY PINCH ZOOM AND PAN TOUCH GESTURES
>>100155947Following sounds easier>download the painted area with a script>diff it with original>paint your diff>repeat until diff comes out emptyI also tried re-pinging dropped packages but even that is not reliable as some are probably dropped on the way from server
buump
>>100154168C doesn't have this problem
>>100156008The echo replies have zero correlation with what gets drawn on canvas. You may get a response for a pixel that never gets drawn, or no response for one that was drawn. Completely pointless to listen for them. At least with my largely unbuffered connection, the biggest gains came from eliminating all packet loss on my side, by careful scheduling. The less bursty the better, for eg a 200kpps (110mbit/s) target, I send 10 pings every 50µs. The improvement in actually received packets is very obvious even on OP's canvas.Senko's canvas https://canvas.senko-san.com/ is great for testing, the only packet loss you see is what's caused by your connection. >>100155108Have you tested how many packets a second you can send back with no loss? Reaching high lossless pps especially on a weaker vps I imagine to be very difficult. I wouldn't bother. I would rather like to see faster canvas updates. And how many pings can the canvas even receive? It seems capturing millions of packets a second is a non-trivial matter as well.>>100158350Instead it has these >>100152116 kinds of problems :D
>>100158410>zero correlation with what gets drawn>all that retrying stuff for fucking nothingGOD DAMNIT>get a response for a pixel that never gets drawnhow does this even work? like server acknowledges my ping, prepares a response and simply forgets drawing the pixel?
>>100159340The responses are generated by the kernel. Not by the canvas program. If the packet gets dropped on its way from kernel to the canvas program, or by the canvas itself, you'll get the echo but no pixel gets drawn.At least that's what's my understanding of it from just reading these threads, I don't have first-hand knowledge of OP's canvas program.
>>100159986>hetznermotherfuckers deleted my account after I sent my legit ID
>>100160008OVH only gives /128 to VPS, Linode only has 1TB traffic, Vultr requires NDP responses for every address, DigitalOcean is expensive AF yet gives very little traffic. I don't think I have a better choice here.
>>100159986That price doesn't seem that bad per TB, what specs server are you on? I've been running my canvas on a i7-4770 from the server auction and I may move it to a ryzen 3700x server since the i7 would ddos itself sending 600k pps at your canvas. Also caching to a webserver saves a ton of bandwidth
>>100159986Another reason to disable ping replies.
>>100158410It doesn't have to be lossless, if you know which pixels were written you can retransmit the ones that weren't. It depends on the NIC/CPU though how many can actually be sent per second.
>>100160466I think the bulk of the bandwidth is from the canvas tiles that need to be refetched in chunks of 196k, and maybe relying on cloudflare to do the compressiondisabling pings would at most cut the usage in half, assuming replies were even 100% of these 15TB of bandwidth use
>>100161895I doubt there's many people staring at the massive fox 24/7, the canvas is rather dead. The fox guy is dumping at least a gigabit at OP to which OP is also replying to.
>>100160106Take a look at my merge request, it should help with initial tile loads and traversing the canvas. I have it up on my server https://canvas.senko-san.com>>100163010I managed to cover his fox with the horse image using only 200mbit and keep it there at 100mbit from a single server
>>100163236Wait so you're telling me, I could hijack the canvas again with just my home internet? Forged IPv6 headers with fake source addresses will go brrrr
I shut it down while I implement compression to save on this ridiculous bandwidth usage.
>>100164769Make the coordinates signed!!
>>100164813I might.
>>100164769>compressioneven if you manage to divide the size by 4 you won't last more than a few days
Someone said Ionos has unlimited bandwidth and provides a /64. Might have a look at it tomorrow.
bump
>>100163236Do you have alpha blending enabled in your server? I'm wondering if I'm doing something wrong or server side
Random idea, if OP doesn't want to disable ping echos outright, what if we could use the ID/SEQ fields to tell OP's server if we want them or not? If they're only disabled for some specific identifier, then normie pings would still get sent back, and those who would want to use the SEQ value for keeping track of what needs to be re-sent can still do so. Now this requires that OP implement the ping echos himself to his canvas program, or merge this https://gitlab.com/necospammer/ipv6-canvas/-/tree/manual_icmp_replies
>>100168048Should be enabledhttps://gitlab.com/senko_san/ipv6-canvas/-/commit/b51808e239ffa76804d29bef35881b22f9de6063Im testing another optimization on my server, I rewrote the per user websocket buffers and pixel update handling. Im using an array that holds all of the changes then flushing per-user the visible changes to them. Should speed up writing to the canvas and should save datas by only sending the newest update to the browser. Also it looks like websocket data is already gzipped by libsoup if the browser supports it and tile data can be compressed and cached off of a web proxy which should be decent data savings for browser traffic. I also allowed zoom out to 0.128x
>>100168062Might be better to use the code byte since it should always be 0 for normie pings, non-zero code byte could request the response. I actually use the extra 32 bits in the header to track x, y, pass #, and instance # for replies (although it's not particularly useful without https://gitlab.com/necospammer/ipv6-canvas/-/tree/manual_icmp_replies being merged)
>>100169172Good idea
>>100168458>.vscode/cringerino
>>100170201get with times, gramps. it the new default
