You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This year we saw a few messages of sizes 30-100 MB, due to people base64-encoding audio and video, which crashed the server. (The simple fix was to delete them from the database, restart the server, then go and advise some students on not doing that so much). We could either make the server handle this somehow, or just disallow them. I think we should disallow them - for these cases, the bots can publish a large blob somewhere of their choosing and just link to it, keeping the messages a reasonable size.
In the database at the end of camp (keeping in mind room clearing deletes from the database permanently), there were about 14,000 messages in total, and the the distribution of message sizes (adding the text, image, media, and state fields) was:
≤ 1 kB
≤ 2 kB
≤ 4 kB
≤ 8 kB
≤ 16 kB
≤ 32 kB
92.82 %
96.80 %
98.98 %
99.43 %
99.98 %
100.00 %
There were very few messages in the 16-32 kB range, but these were still somewhat reasonable (for example, a JSON description which looks like it was meant to be fed into a mapping program to display a polyline). So I think that a 64 kB limit on a message size would be reasonable - this would be most easily implemented by limiting the total size of incoming HTTP requests and bot responses to 64 kB.
The text was updated successfully, but these errors were encountered:
This year we saw a few messages of sizes 30-100 MB, due to people base64-encoding audio and video, which crashed the server. (The simple fix was to delete them from the database, restart the server, then go and advise some students on not doing that so much). We could either make the server handle this somehow, or just disallow them. I think we should disallow them - for these cases, the bots can publish a large blob somewhere of their choosing and just link to it, keeping the messages a reasonable size.
In the database at the end of camp (keeping in mind room clearing deletes from the database permanently), there were about 14,000 messages in total, and the the distribution of message sizes (adding the
text
,image
,media
, andstate
fields) was:There were very few messages in the 16-32 kB range, but these were still somewhat reasonable (for example, a JSON description which looks like it was meant to be fed into a mapping program to display a polyline). So I think that a 64 kB limit on a message size would be reasonable - this would be most easily implemented by limiting the total size of incoming HTTP requests and bot responses to 64 kB.
The text was updated successfully, but these errors were encountered: