Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSockets sends data in 256 bytes fragments #1776

Closed
littlerussian opened this issue Jun 3, 2017 · 1 comment
Closed

WebSockets sends data in 256 bytes fragments #1776

littlerussian opened this issue Jun 3, 2017 · 1 comment

Comments

@littlerussian
Copy link

The WebSocket "send" function splits the outgoing buffer in chunks that are 256 bytes large.
When WebSocket is used with SSL, this creates a 256 byte sequence of messages that must be decoded by the client.
This is inefficient in terms of throughput when using the socket to send buffers that are some KB large.

I don't know if this can be avoided at all or at least allow the user to tweak this value to reduce the overhead. I don't understand why this behaviour is needed.

I think that the code that generates the issue is the StreamOutputRange in the Frame structure, that has a 256 bytes buffer that uses in loop:

websockets.d

struct Frame {
	bool fin;
	FrameOpcode opcode;
	ubyte[] payload;

	void writeFrame(OutputStream stream, SystemRNG sys_rng)
	{
		import vibe.stream.wrapper;

		auto rng = StreamOutputRange(stream);

wrapper.d

/**
	Implements a buffered output range interface on top of an OutputStream.
*/
struct StreamOutputRange {
	private {
		OutputStream m_stream;
		size_t m_fill = 0;
		ubyte[256] m_data = void;
	}

	void put(const(ubyte)[] bts)
	{
		while (bts.length) {
			auto len = min(m_data.length - m_fill, bts.length);
			m_data[m_fill .. m_fill + len] = bts[0 .. len];
			m_fill += len;
			bts = bts[len .. $];
			if (m_fill >= m_data.length) flush();
		}
	}
@littlerussian littlerussian changed the title WebSocket sends data in 256 bytes fragments WebSockets sends data in 256 bytes fragments Jun 3, 2017
@s-ludwig
Copy link
Member

s-ludwig commented Jul 5, 2017

The basic fix is in e1df68e (will be in 0.8.0). A more complete fix is in #1792, which reduces the number of packets to one. The corresponding follow-up issue is #1791.

@s-ludwig s-ludwig closed this as completed Jul 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants