   Very Strange Winsock problem
  I''ve been working on this one for who knows how long now... hours upon hours...BAsically I''m impleementing my own sliding window on top of udp. Thats not really the problem though. I''m looking at log s of my program/dll that I''ve written basically looks like thisClient:Recv''d message 0Sent Ack for 0Recv''d message 1Sent Ack for 1...Sent message 9Recv''d Ack for 9Sent message 0Recv''d Ack for 0 // note this is last message recv''d backSent message 1Sent message 2...Sent message 9// client send window is full waiting for acks// Now if i send a sligthly smaller message (my disconnect command actaully) then the ones i''ve been sending and acking...Sent message -1 //just means no ack neededServer:Recv''d message 0Sent Ack for 0Recv''d message 1Sent Ack for 1...Recv''d message 9Sent Ack for 9Recv''d message 0Sent Ack for 0// now recvfrom (and select which i previously was uisng) both stop recving messages. Despite the fact the client is obviously sending them// Then when client sends the smaller message recv starts working again...Recv''d message -1Recv''d message 1Sent Ack for 1Recv''d message 2Sent Ack for 2...Recv''d message 9Sent Ack for 9Thats all... I have the code but really i dont want anyone here to waste there time on the mess.... I''d just like any winsock expert around who has seen a problem simlar to this to tell me what the heck might be causing it. I thought it was a buffer problem, but my buffer is 2048 and each of the larger messages is only 105 or so. The whole thing seems like it continues working after the first time i send the smaller message. It''s just like it get stopped up with a fwe of the bigger messages and somehow the smaller one breaks everything free... It makes no sense to me and I''m quite tired so I hope it makes sense to someone.Thanks. 
  Still testnig this... the problem boils down to this... recvfrom is return 10035 when I KNOW there is stuff to recv... it keeps doing this until a message of a different size comes in (the data that i know waas there was like 10+ packets of the same size)...Don''t know if this makes any sense to anyone else.. but I''m clueless. ;  Really need help... f any one thinks they can solve this I''ll post codem but it would be troublesome for someone else to look through at best... ;  How do you KNOW there is stuff to receive? It''s likely that recv() is right, and you are wrong.Under UNIX, I''d use strace() to figure out what''s going on. For Windows, you can maybe printf() to a log file for each call you make (and print return values, too). ;  Well I do not think it is possible for someone to solve your problem entirely without further information, I can offer a few things that I would check in this situation. -You said you are using the Select command, make sure that you are calling select on a copy of the original fd_set. Each time before select is called make a copy of the original and pass it in for select.-Are you handeling partial sends and or packets that are combined on the hardware? If so, check to make sure you are not losing packets to partial sends.-Lastly if you are on windows I believe the select command is not guranteed to work with UDP. From personal experience I found it to work only for the first send and then be incorrect. This may have been a bug in my software but I found making the UDP socket non-blocking and disregarding select worked. I hope this gives a few places to start looking. If you still cannot find it, i suggest throwing up a few blocks of code.Regards, Daniel DoptisDDoptis@fatesforgiven.com ;  -You said you are using the Select command, make sure that you are calling select on a copy of the original fd_set. Each time before select is called make a copy of the original and pass it in for select.I was using select and creating a new fd_set each time however, I''ve moved to nonblocking and the same problem is occuring except in the recvfrom instead of select.-Are you handeling partial sends and or packets that are combined on the hardware? If so, check to make sure you are not losing packets to partial sends.Here is where I could be doing something wrong... I was under the impression that UDP gauranteed  afull uncorrupted packet or nothing. Can someone clarify this for me?-Lastly if you are on windows I believe the select command is not guranteed to work with UDP. From personal experience I found it to work only for the first send and then be incorrect. This may have been a bug in my software but I found making the UDP socket non-blocking and disregarding select worked. I am on windows, but as per number 1 I''m no longer using select.Thanks for the input! Any ideas are better than nothing.I''ll try to post some code when I get home today. ;  Just saw hplus''s reply...I''m fairly sure there is data there to recv as I am printing just about every command to a log file... If you havea better way of finding out whats really being sent please tell me. But I''m using sendto and its returning the size of the data sent, which is correct. And I''m not losing them sending them to myself I hope. ;  Uncorrupt yes, but complete no.This is where basic sockets can get hairy. If you are sending really big packets then it may send only part of the packet when you call sendto or send. Those functions return the amount of bytes sent so you may want to check to make sure its sending the entire packet. Also if you are sending multiple packets very fast one after another the hardware can and will combine packets and send them out together. To solve these problems you want to confirm the sizes of data read on the recieving end. If the size is too small then pitch the packet since it is not a complete packet (if this happens often then you need smaller packets). If the size is too big, then you have combined packets and need to handle parsing them from the buffer you read into. Hope this helps, Daniel Doptis ;  I''m going to rip the code out of my different projects and write a very simple test example which hopefully exhibits the same problem. Then I''ll post that code here and maybe you guys can point out what I''m doing wrong. So look back here later tonight! ;  Ethereal is a freeware ethernet tracer which is really useful. I haven''t tried it on a machine talking to itself, but hopefully you can set up a case where more than one machine is involved, and sniff that. (You''d need to, for testing, anyway) 