I think the two problems are related. We don't officially WebSockets, but SocketIO can fail over to using long-poll HTTP/HTTPS as an alternative. The way that works is that your JavaScript code will make a request to your website, and then keep the connection open -- the server will also keep it open, so it can then feed data back along that connection.
However, it's unlikely to work well. Your website has one worker process handling all requests (if you had a paid account you'd have two or more processes). When a request comes in, the worker starts handling it, and will continue to do so until the connection is closed.
What this means is that while your JavaScript code and the server are keeping a request open so that SocketIO can send data back and forth, your worker process is busy handling that one connection. Any further requests that come in for your site will be blocked until the connection is broken.
So while you might be able to get an experimental site up and running, it certainly would not work well in practice.
The OSError: write error that you're seeing is related. If our system detects that a worker process has spent more than five minutes processing a request, it assumes that it has crashed and restarts it. When that happens, the way that the connections are shut down will generate an error like that in the logs. So I think what's happening is that your JS code and the server are trying to keep the connection open, and then after five minutes the timeout cuts in.