I am writing basically a chat program using C++ and Winsock. Im getting a strange problem when I connect to the server with the client. I have two pc's. During testing I have been running the server and a client on the same pc and connecting a second client with my second pc. The server seems to be functioning correctly. It recv()'s the data, prints it to a screen, and uses select() to send the data to each connected client. As far as the clients, everything works 100% correctly if the clients are in debug mode. If they arent in debug mode it prints out the entire buffer and the data in the buffer is garbage. I put breaking points right after the recv() calls on the client. As I "F5" through the breakpoints all the varibles are correct and it correctly prints the message out on the client. I have also noticed that the client that is running on the same pc as the server is working fine in or out of debug mode. Only clients on separate pc's seem to be having this problem. Im hoping this is something very trivial and that someone might have ran into this before. Does anyone have any ideas? Thanks in advance. ***UPDATE*** Since I posted this I tried out a idea and thought maybe the debugger was stopping the program at the breakpoint so I put in Sleep(300); and it jury rigged my problem. It is now printing out the message correctly instead garbage. Can anyone explain whats going on with this? Surely my pc isnt too fast. Why does it need to slow down while accepting the message from the server? And can someone explain how to achieve this same result without using Sleep(); ? [edited by - Pip on December 3, 2003 3:44:39 AM] [edited by - Pip on December 3, 2003 3:45:56 AM]

I think I figured it out now.

I forgot that I used ioctlsocket(); when I was trying to figure out how I should make my socket not get blocked by recv() calls. As I was looking over my code I knoticed it and commented it out and the sleep() call and it seems to be working properly now. Hopefully its good to go finally.

I used FD_SET and select() on my client to see if the server had any data ready to be read so it wouldnt block my recv() call. I had just forgot to take the ioctlsocket out after I went that route instead.

Thanks

You are using non-blocking sockets? I have been playing around with that too, but I can''t seem to get the client working properly... When I use the select() function I need to have a timeout value of about 500 000 microsecs, or else it won''t get any incoming data...? Any ideas? I use select() on the server as well, but I can set the timeout value to 0 for secs and for microsecs and it still works, as opposed to my client...

-Trond

Under a non-blocking I/O model, data packages are sent and received in random order. It is up to the application to analyze and reorganize the packages.

Kuphryn

[edited by - kuphryn on December 3, 2003 3:10:46 PM]

non-blocking has nothing to do with ordering of the data. If you use TCP then the data is guaranteed to be received in the same order it was sent. If you use UDP it isn''t. Whether you block on the receive (or send) is irrelevant.

We need more info to help u. If u could post a code snippet of the possibly offending code, perhaps we can better help u out.

However from the given data, it seems to be a timming issue. Perhaps your code has some internal latency which doesnt push the packet out unitl X secs. Or something like Nagels algorithim is queueing up the packets until they reach a threshold. Or maybe ur using UDP, which is an odd protocol choice for a chat program.

-ddn

If you are trying to use ioctlsocket(); and FD_SET/select() on your server comment out the ioctlsocket(); and see how it works then. I accidently left it on from where I was experimenting and it wasnt recieveing any data unless I put a sleep() on it.