#WINSOCK SEND CODE#
It's a common problem in Winsock programs, and one that goes unacknowledged in most of the FAQs here or in most tutorials you will find.I am writing a simple 1 client console chat program and I am having a small problem on the serverside.īasically The client was just copied server code modded to connect instead of accept connections, it works great, but the server when it receives data and outputs it, it has a couple of extra characters, I have written other diatribes on this elsewhere, such as Other thread. However, they may often end up with less than one message. This means since A never sends another message until B sends a reply, your receive buffers will never have more than one message's data in them. If your application is really simple, it may be completely transactional in nature.
#WINSOCK SEND FULL#
Worse yet, the buffer might have a full message (or several) and part of another one. The program needs to look at what's in the buffer and decide whether it has a whole message to process. Once you have the convention in place, your receiver needs to be modifed further.Ī data arrival event really just tells the receiver that some (not necessarily all) data has been received. Other people like to use a binary message-length prefix. A simple end-of-message delimiter can do the trick. You need some convention set between your sending and receiving program to signal each other where messages start and leave off. This takes us back to the delimiters, or message framing. Usually either a slow network link or large messages (such as a file transfer) need to enter the picture before these almost-working programs finally fall over. If you are working over a LAN or other network which is fairly "fast" compared to your programs' thirst for data you often won't see this issue. This is often masked when a programmer starts working with TCP connections, and UDP has its own hidden quirks. Network devices between the sender and receiver machines may also re-chunk the data to fit the intermediate media: there are lots of types of networks besides ethernet out there, and dial connections have their own special characteristics, just like frame relay and other technologies on the Internet at large. A TCP send via Winsock merely puts data into an outbound buffer, and the TCP stack and the layers below it clock the data out onto the wire at their own pace and using media-dependent packet sizes. In real networks TCP traffic doesn't pass instantaneously, or in "chunks" of the size we (think we) send. Just as we need some convention in a text file to delimit lines (or "records") we need some convention to delimit messages when we send them over a TCP stream. There are no "records" in such a file, but by convention we consider strings of text delimited by CrLf to be "lines" and almost as good as records.Įssentially, programmers often assume that when one end does a "send" of a hunk of data, the other end can do a (single) "receive" and exactly that hunk of data will end up in the receving buffer.
#WINSOCK SEND PC#
The bursty nature of many applications can fool a programmer into thinking otherwise, but listening on the receiving end of a TCP connection is like reading a PC text file. TCP by itself does not provide a messaging or datagram service: it provides a stream.Ī stream is just what it sounds like: a bunch of bytes streaming from the start of the connection until it ends. People like to speak blithely of "packets" when what they really mean are messages. Is it possible you are tripping over a common misunderstanding of how TCP streams work?
0 kommentar(er)
