🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

the Winsock function call that never returned....

Started by
4 comments, last by Yanroy 23 years, 8 months ago
I posted this question in the general forum, but it has been ignored for the past few days... I though someone here might be more interested. You can find that post here. Thanks ahead of time. Please post replies to that thread, not this one --------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

--------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming
You are unique. Just like everybody else.
"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor

Yanroy@usa.com

Advertisement
There are just too many possiblities from just the description of the problem. The best way we can assist you is if you post some code. Specifcly the send and recv portions of the client and server respsectively.

The possible errors could include:
-improper initilization of sockets
-improper init of data structs associated with sockets
-logic error in recv loop or send loop
-as mentioned buffering (even then the buffering only delays the message, it wouldn''t indefintely block it)

-ddn
Apparently you didn't read my post(s) very carefully. If you read the one above, there is a link to another thread, where this discussion has ground to a halt (and I need the answer!). In the second-to-last post by me in that thread, there is a link to the .cpp that makes up most of my .dll for winsock. Please direct you attention there... Thanks for the reply.

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming


You are unique. Just like everybody else.

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

Edited by - Yanroy on October 19, 2000 10:48:52 AM

--------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming
You are unique. Just like everybody else.
"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor

Yanroy@usa.com

It sounds like the server has FD_ACCEPT enabled, but not FD_READ. It should be at the AsyncSelect function.

...Probably you''re best bet at this point is to get a hold of a program called NetXRay. It''ll let you know exactly whats going on over the network. That way you''ll know exactly if it''s the client or the server.
You''re server code, as it stands, won''t work. In fact, my guess as to what it does any recv will almost certainly return a SOCKET_ERROR (with an error message of WSAEWOULDBLOCK) and then you''ll reset the connection.

First, in response to the other thread, DON''T turn off the Nagle algorithm. It will have no effect on your problem and is one of the big no-no''s in the winsock FAQ.

Now the reason I say your server code won''t work is that you''re specifying that it use non-blocking sockets. Basically what happens with non-blocking sockets is if you try a read and there''s no data to read, instead of waiting for some it returns SOCKET_ERROR and WSAGetLastError() will return WSAEWOULDBLOCK (which means "I would block on this socket until data is available because there''s none there right now except that this socket is in non-blocking mode so I can''t"). You cannot treat any SOCKET_ERROR condition as a failure to trigger a reset. Often a socket call returns an error condition for a successful operation. Check the documentation of each call for what errors it may return and figure out how you want to respond to them.

Also, you didn''t post the client code. Are you sre your client code is right and that it''s sending the string?
I''ve heard many times that nagle is bad for gaming, it causes increases in lag delays. For games you (generally) would want to trade bandwidth for lower latencies.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

This topic is closed to new replies.

Advertisement