asynchronous sockets FD_ACCEPT
Author
Hi.
I have one final question... I am trying to create a small server
application using asynchronous sockets, but someting is going wrong even
though I have followed the few tutorials I have found on the Internet. I was
hoping someone with a bit more experience than me could take a look and give
me a hint on that is going wrong.
When starting the application and pusing the menu so that the
ID_CLIENT_LISTEN event (I know the name is stupid) is triggered I set up and
bind/listen the socket for getting connection. When connecting to the server
with telnet the telnet window goes blank, and just stand there. I have made
the conclution that it manages to get status "connecting", but not acctually
ever get the status "connected". I can NOT recive data in the FD_READ, and
when using send() it return -1.
The code is pasted below:
http://www.pastebin.org/index.php?page=show&id=1673&key=wnak30x62k
I am gonna go out on a limb as I am not familiar with telnet, however I have dabbled with winsock a bit. Perhaps the problem is that telnet is a protocol, as in it expects certain types of packets to be sent and recieved. Perhaps your server works just fine, but the client is expecting something it isnt getting. I would suggest programming up a simple chat program without the telnet protocol, just sending straight up char arrays back and forth. When you get the hang of that then study up on telnet and how it works. All in all I would not expect the telnet client to behave in any particular fashion without much research.
Author
you were correct! great man!
when connection to the server with my irc client it worked. the problem now is to send data when someone is connecting. it doesnt work to use send() in the FD_ACCEPT event since the connection usually are a bit slower than the code (source: msdn). Any idea how I can fix this and send data to the client when accepted?
when connection to the server with my irc client it worked. the problem now is to send data when someone is connecting. it doesnt work to use send() in the FD_ACCEPT event since the connection usually are a bit slower than the code (source: msdn). Any idea how I can fix this and send data to the client when accepted?
Author
well I am not coding a telnet client or server, I am just experiencing with sockets...anyway back to the problem...How can I send data to the socket right after accept() ?
send() will not work because of the delay between accepting and connected.
send() will not work because of the delay between accepting and connected.
When you accept from the listening socket, you will receive a new handle to the connected socket. This new handle will have some of the same properties as the listening socket - including the asynchronous event handling properties. If you have set up the listening socket (and therefore the connected socket, since it inherits the properties) to receive FD_WRITE notifications, then you should get a socket event message as soon as the socket is ready to send. Once you have received that message, you will be able to call send() as many times as you want, and you won't get another FD_WRITE notification until one of your calls to send() fails. Once a call to send() has failed, you will receive another FD_WRITE notification when it is ready to send again, and then you can carry on.
When send() fails, you should call WSAGetLastError(). If it returns WSAEWOULDBLOCK, then you should keep the buffer of what you're trying to send (so that you can try sending it again, when the socket is ready) and then wait for another FD_WRITE message before continuing.
The most obvious way to handle sending with asynchronous sockets is to have a send buffer for each connection. When you want to send something, add it to the end of the buffer, then try and send the entire buffer. If the send fails with WSAEWOULDBLOCK, then dump out of your sending function, and pretend it worked (you'll send the information later). If the send succeeds, then remove the appropriate amount of data from the beginning of the buffer (appropriate amound being the number of bytes that were actually sent - as returned by the send() call). When you receive an FD_WRITE notification, then try and send everything that's in the buffer, and again remove the data that does get sent (if any) from the buffer. Don't forget that you can never be absolutely certain that send() will succeed. Even if you're calling send() from within your FD_WRITE handler, send() could still return an error - even WSAEWOULDBLOCK.
Hope that helps,
John B
[edited by - JohnBSmall on August 20, 2003 10:34:24 AM]
When send() fails, you should call WSAGetLastError(). If it returns WSAEWOULDBLOCK, then you should keep the buffer of what you're trying to send (so that you can try sending it again, when the socket is ready) and then wait for another FD_WRITE message before continuing.
The most obvious way to handle sending with asynchronous sockets is to have a send buffer for each connection. When you want to send something, add it to the end of the buffer, then try and send the entire buffer. If the send fails with WSAEWOULDBLOCK, then dump out of your sending function, and pretend it worked (you'll send the information later). If the send succeeds, then remove the appropriate amount of data from the beginning of the buffer (appropriate amound being the number of bytes that were actually sent - as returned by the send() call). When you receive an FD_WRITE notification, then try and send everything that's in the buffer, and again remove the data that does get sent (if any) from the buffer. Don't forget that you can never be absolutely certain that send() will succeed. Even if you're calling send() from within your FD_WRITE handler, send() could still return an error - even WSAEWOULDBLOCK.
Hope that helps,
John B
[edited by - JohnBSmall on August 20, 2003 10:34:24 AM]
Author
Thank you for the reply!
I have trouble seeing what you mean with the FD_WRITE event...
[edited by - invictus on August 21, 2003 3:49:25 PM]
I have trouble seeing what you mean with the FD_WRITE event...
[edited by - invictus on August 21, 2003 3:49:25 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
