mleku @mleku - 10mo
#notolargebinaryevents #meme #nostr #devstr
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
semisol @Semisol - 10mo
did you configure the max frame size on both your client and server
hah, yeah, well, i didn't write this code originally, and it uses two different things, one for client, wsutil, and fasthttp/websocket for the relay i'm gonna have to look at this because this is super annoying been searching around the source code and libraries to see where i can set frame limits but best i could do was find an unresolved issue on gorilla websockets that has no progress on it, and i read what was written in the issue and it seems like websockets are almost as bad as javascript in terms of compliant, interoperable standards
