Mail Archives: djgpp/1997/01/07/17:53:11
Dan Hedlund <markiv AT rangenet DOT com> wrote:
>Alexander V. Lukyanov wrote:
>>
>> > I don't know, I have to get connect and accept to work first. Do you
>> > know where I can find any information on wsock.vxd?
>>
>> I know little about winsock, but I programmed for unix sockets.
>> Can the problem with connect / accept be caused by reversed byte
>> order in port number? It is needed to use htons(port) as
>> the part of sockaddr. For this reason my own program worked
>> on Sparc (most significant byte first) bye did not on ix86.
>I found the problem!!! I was using a stream socket instead of a
>datagram socket. It just sucessfully connected to my http server.
Datagram sockets are connectionless, thus it is not surprising that a
connect() call on UDP sockets succeeds, as this will only assign a
default recipient for send() calls. No network traffic is generated,
no "connect" message is sent, and generally you can't call it
"connecting" as such.
I've programmed 16-bit winsock, and here's my suggestion.
When it comes to connecting stream sockets (TCP), it's quite possible
that the sockets created by this VXD is "nonblocking" sockets. What
nonblocking means in this case is:
connect() will return an error code WSAEWOULDBLOCK, to signal that the
request cannot be satisfied immediately. However, it will background
the connect. Whenever it has successfully connected, it will be marked
writeable by select(), and/or you might get a notification message if
you had used WSAAsyncSelect(). (If it failed connection, it will be in
the exceptfds in select(), and/or you would get a WSAAsyncSelect()
notification.)
This would explain the error codes you get. You could try verifying it
by finding an equivalent of WSAGetLastError().
- Raw text -