no way to interrupt incoming messages (eg. data of a remote function call)

[tommedema]

If a client calls a remote function on the server, there is no way to interrupt this stream of data from the client to the server.

In essence, a function call acts "synchronous" because the server waits for the clients to finish sending all parameters and then executes it on the server.

This means that a client can send huge piles of data within a function to a server, causing the stream to take up way too many resources and be too time intensive.

Thus, it has to be possible to validate incoming streams and be able to kill the connection if too much data is being send.

[ericz]

Hey tom,

Yes this is a fix that we should be implementing ("validate incoming streams" and kill it if it is sending too much data to prevent overuse of server resources).

If you made a function call with a giant amount of parameter data, this won't be synchronous however because the transfer of that data and storing it in memory on the server is all asynchronous. The server will not wait synchronously for the parameters of a function to load fully. That function will simply be called after all data is loaded into memory. The only process there that is synchronous is the deserialization, which may be a problem.

However the issue is still that the memory can be swamped as that data WILL be stored in memory.

Excellent point. I didn't think of this method in our previous discussions.

[ericz]

This might not be possible.

Socket.io exposes incoming data not as a stream but as discrete messages. Any validation we write would have to be after the message has been accepted. We could possibly intercept a malicious message before it gets JSON.parsed which would save us some time but even then the damage to memory use would've occured.

Socket.io v0.7 will be exposing lower level things like the parser so that will be easy to implement (will not have to fork socket.io) in the new version.

In any case this is really more of a socket.io issue so I am closing for now.

Thanks for the issue tom.