#notolargebinaryevents #meme #nostr #devstr
Discussion
seriously, backing up events across the network is already hard enough without having to deal with websockets freaking out at message sizes
websockets = small, high frequency messages
http = has resuming capability for extremely large downloads
when i was a youngin, there used to be no resume on HTTP, imagine the nightmare of downloading 20mb for 3 hours and then your mother uses the telephone just as it's 300kb from done
i'm pretty sure that there's something wrong with the websocket library i'm using here (inherited from khatru) it chokes on anything over 256kb
well, tried swapping to gorilla, same problem ... just gonna slow down the event blower because it seems like if it gets enough time between the floods it is ok
not real impressed though... this is going on my slate for improvements for future... a websocket library that can cope with more than a few megabytes per second
what is this, a network connection for ants?
do i need to fan out my blower connection to several websockets? is there some real limitation here because i've pumped tens of megabytes per second through tcp sockets on gigabit wired connections... i certainly hope that on high load these websockets can handle more than this or the partitioning/sharding strategy needs to be more emphasised
no, there really is a literal issue with event sizes much over about 200kb i even tried to lower it to 256kb and that's still too much
trying 192kb now as a max limit to send, seems to be happy now, anyone who knows golang websocket programming maybe you can inform me
#asknostr #golang #websockets #wtf
I've been unironically living with 128kbps down this week because I ran outta hotspot data and im being throttled 🫡