Advertisement

Scatter / Gather for server read

Started by January 22, 2018 04:43 AM
2 comments, last by Saruman 6 years, 10 months ago

I just have a quick question as I've looked around but really haven't gotten a credible answer on the topic.

I have a server using TCP sockets and IOCP sending a custom binary protocol / flatbuffers. I just switched to using a scatter/gather approach for writing in order to avoid the memory copies into a large send buffer, as this way I can just burn direct from the packet queue. It worked out great, and I'm happy with the improvement as it's a noticeable gain with a large amount of clients / traffic.

What I'm wondering is if people are using scatter / gather on server reads? And if so what are the benefits to doing so? It was very easy to see the benefit for writes, but I'm not really sure what I would actually gain on read. I figured since I'm making changes at this level it might be wise to do so now if there is a benefit that I'm not seeing.

EDIT: Also I guess I should mention that incoming packets are variable length, otherwise that would be an easy to see win :)

You can still do variable length with scatter reads. For example, if your network protocol always has a fixed-length header, you could put that into a different area than the main packet data.

I wouldn't really expect this to add a lot of efficiency, though. For TCP, you are never guaranteed to only get a single packet, so the scatter read could over-read into the beginning of the next message's fixed-size bit. For UDP, you'd correctly get the first N bytes of each packet, but the gain compared to just keeping those bytes at the head of your regular buffer, and incrementing the read pointer for whomever takes the data from you, is likely small to nonexistent.

 

enum Bool { True, False, FileNotFound };
Advertisement

Thanks for the input! Those were basically my findings, but I wasn't sure if I was missing something.

In a perfect world I'd have fixed sized packets using scatter / gather with RIO :/

This topic is closed to new replies.

Advertisement