WebSocket will close connection for large payload about telegraph HOT 10 CLOSED

@Zyphrax I have created sample app here https://github.com/mikina/TelegraphSocket

from telegraph.

I've fixed the slow websocket parsing in commit ed55f1a 🎉
On my Mac mini, parsing the output1.json payload went from 1 minute 20 sec. to 80 milliseconds !

I'll probably release a new Telegraph version tomorrow.
I have a few more fixes that I want to add to the new version as well.

from telegraph.

Unfortunately WebSocket communication is a bit limited in Telegraph. I haven't implemented the full spec. However a payload of 1MB should work.

Do you have a small example app for me to test this?

from telegraph.

@mikina Thank you. The WebSocket framing protocol is optimized to handle messages of different sizes. WebSocket frames look like this:

// Base Framing Protocol (https://tools.ietf.org/html/rfc6455 - 5.2)
//
// |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
// +-+-+-+-+-------+-+-------------+-------------------------------+
// |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
// |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
// |N|V|V|V|       |S|             |   (if payload len==126/127)   |
// | |1|2|3|       |K|             |                               |
// +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
// |    Extended payload length continued if payload len == 127    |
// + - - - - - - - - - - - - - - - +-------------------------------+
// |                               | Masking-key, if MASK set to 1 |
// +-------------------------------+-------------------------------+
// |    Masking-key (continued)    |          Payload Data         |
// +-------------------------------- - - - - - - - - - - - - - - - +
// :                     Payload Data continued ...                :
// + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
// |                     Payload Data continued ...                |
// +---------------------------------------------------------------+

I think Telegraph might contain a 🐞 when it comes to the Extended payload part. I'm investigating the issue and hopefully I can fix it 🙂

from telegraph.

Awesome! @Zyphrax let me know if I can help more 😊

from telegraph.

Ok, I found two bugs:

1. Telegraph has a few helpers to convert UInt16, UInt32 and UInt64 values to an UInt8 array. The UInt64 helper was unnecessarily complex and didn't seem to return the correct array.
2. The WebSocketMessage+Write class has a small issue where payload sizes above Int16.max would be considered a large payload. That is not according to spec, it should be UInt16.max instead of Int16.max.

I'll commit these changes after this. You can use the HEAD version of Telegraph by specifying this in your Podfile:

pod 'Telegraph', :git => 'https://github.com/Building42/Telegraph.git'

The web socket message no longer fails, but for some reason it is reallllllly slow. It takes a bit over 1 minute on my machine to send the output1.json message. So that's the next 🐛 I need to squash.

from telegraph.

The performance issue seems to be caused by the WebSocket frame parser. I have to rework the part that processes the payload a bit. I'll keep you posted.

from telegraph.

Thanks for the information and thank you for taking care of this 😊

from telegraph.

Excellent news 🎉 I will test it and let you know 😊

from telegraph.

Fixed in 0.17

from telegraph.