hi there,
writing an winsock 1.1 application I'm wondering how to make sure two sent packets (there might be very little time between them) are not received as one packet? I'm using WSAAsyncSelect to receive notifications as wnd msgs.
Dom
writing an winsock 1.1 application I'm wondering how to make sure two sent packets (there might be very little time between them) are not received as one packet? I'm using WSAAsyncSelect to receive notifications as wnd msgs.
Dom
you'd better use UDP not TCP
hi zenglei, no chance i need tcp...
Is it ok to just make a 100-ms-sleep call between the sendings?
Is it ok to just make a 100-ms-sleep call between the sendings?
i think you can never be sure about it. if your own made protocol needs seperated packetes, your protocol lacks something.
Add some sort of End of File character at the end of each packet sent that you can look for when receiving. Once a complete packet is received, notifiy another thread or call a proc to handle your complete packet...???
perhaps this may hold the answer for you:
http://www.tangentsoft.net/wskfaq/articles/effective-tcp.html
I also read the beginning of "Effective TCP/IP Programming: 44 Tips to Improve Your Network Programs" by Jon C. Snader
http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=2V11BR2AmD&isbn=0201615894&TXT=Y&itm=1
I liked the format and hopefully this book can help you too. The socket API has a seductively simple feel to it, as he explains, but due to the nature of computer networking, there are underlying complexities beneath it.
http://www.tangentsoft.net/wskfaq/articles/effective-tcp.html
I also read the beginning of "Effective TCP/IP Programming: 44 Tips to Improve Your Network Programs" by Jon C. Snader
http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=2V11BR2AmD&isbn=0201615894&TXT=Y&itm=1
I liked the format and hopefully this book can help you too. The socket API has a seductively simple feel to it, as he explains, but due to the nature of computer networking, there are underlying complexities beneath it.
thx to all...
i think you can never be sure about it. if your own made protocol needs seperated packetes, your protocol lacks something.
so now I'm sure my protocol needs some more time to be spend on...
The reason for my problem is that I'm actually writing a client which has to list all answers on specific sendings in a listbox. As I deal with winsock1.1 and window message notification (maybe that's a thing to change next to protocol standards) I simply give the sendings right after i got the last answer packet. When I use it over a fast connection (LAN) some answer packets join and therefore do not show up as a single item in the list box. To add a 100-ms-Sleep after each answer packet / new request packet did solve this prob but seemed to be some kind of dirty programming to me so I wondered if there is any default code to use in order to be sure no packets are received together.
Concerning Zenglei: UDP packets never join???
Dominik
i think you can never be sure about it. if your own made protocol needs seperated packetes, your protocol lacks something.
so now I'm sure my protocol needs some more time to be spend on...
The reason for my problem is that I'm actually writing a client which has to list all answers on specific sendings in a listbox. As I deal with winsock1.1 and window message notification (maybe that's a thing to change next to protocol standards) I simply give the sendings right after i got the last answer packet. When I use it over a fast connection (LAN) some answer packets join and therefore do not show up as a single item in the list box. To add a 100-ms-Sleep after each answer packet / new request packet did solve this prob but seemed to be some kind of dirty programming to me so I wondered if there is any default code to use in order to be sure no packets are received together.
Concerning Zenglei: UDP packets never join???
Dominik
Dom, TCP is a "streaming" protocol, not "packet-based" like UDP. To do what you want, either prefix the strings by a length byte, or use the NULL terminated strings. Any other workaround is *not* okay when using TCP, you need to fix your protocol.
Hi f0dder, thanks for your statement...
well actually the protocol already includes a termination character (just like Dude pointed out, too). Although UDP seems to be quite nice to use for it is packet-based I never wrote an UDP prog as you never can be sure wether there is someone who receives the packet or not. The big feature that comes with TCP is most likely the secure connection (3-handshake etc.).
Dom
well actually the protocol already includes a termination character (just like Dude pointed out, too). Although UDP seems to be quite nice to use for it is packet-based I never wrote an UDP prog as you never can be sure wether there is someone who receives the packet or not. The big feature that comes with TCP is most likely the secure connection (3-handshake etc.).
Dom
Yes, TCP is nice because you're guaranteed that the data reaches the other end (or you will get an error if it doesn't). I've seen people implement basically "TCP emulated with UDP", just because they wanted to handle "packets" - IMHO it's better to become familiar with the streaming nature of TCP.
UDP is more useful where you cannot tolerate the slight latency of TCP (ie, fast-paced games), or where you can live with a few dropped packets (video streaming).
UDP is more useful where you cannot tolerate the slight latency of TCP (ie, fast-paced games), or where you can live with a few dropped packets (video streaming).