Re: ORBit2 on Win32

["Karl Waclawek" <karl waclawek net>]

> Hi Karl,
>
> On Tue, 2002-09-17 at 15:53, Karl Waclawek wrote:
> > > Yes - we don't support that.
> >
> > So the orbit-mt project still has value...
>
> Yes.
>
> > AFAIK, the windows sockest can be used in a truly asynchronous way,
> > i.e. the OS call you back, no polling needed.
>
> Interesting; in a separate thread as it were ?

I think so.
You pass a window handle to the WSAAsyncSelect call, and this window will
receive socket events as messages to be processed by its message loop.
AFAIK, this window does not have to belong to the same thread.

I would assume that would require a significant number of Windows
specific #ifdef'ed code?

Then there is yet another way of doing it: Overlapped I/O.
Here is what the docs have to say, to give you  an idea:
(I am not expert at it, just in case you have that illusion)

<excerpt>
Overlapped I/O and Event Objects
Windows Sockets 2 introduces overlapped I/O and requires that all transport providers support this
capability. Overlapped I/O follows the model established in Win32 and can be performed only on
sockets created through the WSASocket function with the WSA_FLAG_OVERLAPPED flag set or sockets
created through the socket function.

Note Creating a socket with the overlapped attribute has no impact on whether a socket is currently
in the blocking or nonblocking mode. Sockets created with the overlapped attribute can be used to
perform overlapped I/O—doing so does not change the blocking mode of a socket. Since overlapped I/O
operations do not block, the blocking mode of a socket is irrelevant for these operations.

For receiving, applications use the WSARecv or WSARecvFrom functions to supply buffers into which
data is to be received. If one or more buffers are posted prior to the time when data has been
received by the network, that data could be placed in the user's buffers immediately as it arrives.
Thus, it can avoid the copy operation that would otherwise occur at the time the recv or recvfrom
function is invoked. If data is already present when receive buffers are posted, it is copied
immediately into the user's buffers.

If data arrives when no receive buffers have been posted by the application, the network resorts to
the familiar synchronous style of operation. That is, the incoming data is buffered internally until
the application issues a receive call and thereby supplies a buffer into which the data can be
copied. An exception to this is when the appliation uses setsockopt to set the size of the receive
buffer to zero. In this instance, reliable protocols would only allow data to be received when
application buffers had been posted and data on unreliable protocols would be lost.

On the sending side, applications use WSASend or WSASendTo to supply pointers to filled buffers and
then agree to not disturb the buffers in any way until the network has consumed the buffer's
contents.

Overlapped send and receive calls return immediately. A return value of zero indicates that the I/O
operation was completed immediately and that the corresponding completion indication already
occurred. That is, the associated event object has been signaled, or a completion routine has been
queued and will be executed when the calling thread gets into the alertable wait state.

A return value of SOCKET_ERROR coupled with an error code of WSA_IO_PENDING indicates that the
overlapped operation has been successfully initiated and that a subsequent indication will be
provided when send buffers have been consumed or when a receive operation has been completed.
However, for sockets that are byte-stream style, the completion indication occurs whenever the
incoming data is exhausted, regardless of whether the buffers are full. Any other error code
indicates that the overlapped operation was not successfully initiated and that no completion
indication will be forthcoming.

Both send and receive operations can be overlapped. The receive functions can be invoked several
times to post receive buffers in preparation for incoming data, and the send functions can be
invoked several times to queue multiple buffers to send. While the application can rely upon a
series of overlapped send buffers being sent in the order supplied, the corresponding completion
indications might occur in a different order. Likewise, on the receiving side, buffers will be
filled in the order they are supplied, but the completion indications might occur in a different
order.

Canceling individual overlapped operations pending on a given socket is impossible. However, the
closesocket function can be called to close the socket and eventually discontinue all pending
operations.

The deferred completion feature of overlapped I/O is also available for WSAIoctl, which is an
enhanced version of ioctlsocket.

</excerpt>

> > > Interesting - we need to integrate with the glib mainloop (the polling
> > > mechanism), I don't think glib1 did that. But if we can poll on those
> > > handles, then yes fine. It's possible we want a custom IO handler inside
> > > linc-protocols.c or somesuch [ assuming we can read/write on a windows
> > > socket ? ]. Also, we rather rely on doing non-blocking I/O, I imagine we
> > > should only copy the glib1 bits if we need to;
> >
> > Now, does this mean you are doing this?
>
> Nope :-) I'm just wondering if there's win32 bits from ORBit that we
> need to merge into linc; just splitting out the win32 bits from ORBit
> into a diff would be interesting to see if we can merge them into linc
> or somesuch.
>


I sent an e-mail to the original contributor of the Win32 ORBit port.
Maybe he is willing to lend a helping hand.

Il'l try to do a diff when back at home.
Just have to know which exact version of ORBit I have to diff against.

Karl