I finally started learning how to program with winsock - and Scatter/Gather IO is AWESOME! It might even be better than asyncronous IO or completion ports... it''s a close call. I was wondering if anyone else is using scatter/gather and if there''s any caveats to it... it seems like it could even increase performance slightly on top of making serializing easier. Magmai Kai Holmlor "Oh, like you''ve never written buggy code" - Lee "What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

I think you are mixing up your I/O models. Scatter-Gather I/O is a technique that allows you to transmit fixed-size data chunks using multiple buffers (typically headers that identify the body, contained in another buffer.) This means you don't have to perform a memcpy to concatenate the data into one buffer before calling WSARecv/WSASend. This doesn't have anything to do with Asynchronous I/O or I/O Completion Ports. Async IO/Completion Ports is a mechanism for notification and processing of completed I/O.

A problem with scatter-gather I/O is that there is no guarantee that *all* the receive buffers will be filled before the receive call returns.

I can't really see any performance advantages of using SGIO other than the fact that you can avoid a couple user-mode copies(memcpy) when sending/receiving the data. This is a good argument for using SGIO when the data being sent is relatively fixed in size/format. Still, by designing your application properly you can avoid the memory copies as well too.

No other I/O model on Windows NT/2000 is as fast as I/O Completion Ports.

EDIT: In an asynchronous environment, managing multiple buffers for scatter-gather I/O could become troublesome...

Disclaimer: I've only used scatter-gather I/O a few times and so I haven't had much of a chance to gauge the performance, so in your particular instance it could be very useful. Still, SGIO has nothing to do with Asynchronous I/O / Completion Ports.

Dire Wolf
www.digitalfiends.com

Edited by - Dire.Wolf on December 18, 2001 1:28:51 PM

I meant that scatter gather IO is yet another good reason to use platform specific sockets, on-top of asyncronousity and kernel completion

I see scatter/gather being most suited to unfixed sized packets.

For the rtp protocol, which I'm working on, I'd have to memcpy about 5 times to serialize a packet, with sgio I just keep a fixed WSABUF around and fill-in 5 descriptors prior to calling the send function. It eliminates the need for a circular memory pool for buffering the packet stream. (Course, you have to maintain the integrity of the chunks pointed at until completion now).

For receiving I don't see at as big a benefit, but it would let you allocate and use non-continuous chunks of memory to receive data (makes handling a buffer-overrun easier).

The important part about sgio is that they all go into one packet (I orginally thought it just let you send multiple packets at once).

One thing I did think of that makes them not-so-great is if you want to compress or encrypt the data stream. You either give-up sgio, or make those routines change the sgio chunks (which means the chunks need to be copies...).

quote:
A problem with scatter-gather I/O is that there is no guarantee that *all* the receive buffers will be filled before the receive call returns.

Even after the overlapped event signals with async IO?
(My code is exhibiting odd behavior at the moment, and I was starting to think I'm dropping UDP packets on my LAN...probably a bug)

Magmai Kai Holmlor

"Oh, like you've never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Edited by - Magmai Kai Holmlor on December 18, 2001 8:36:57 PM