mmiers

I have a simple question. I've read in many vb.net networking articles that when u send a peice of data, u should split it up into chunks and send each one. Then it goes into what is an optimal "buffer size" . Could someone explain the need to split up packets when sending? I know that when u recieve, packets can be split up or stuck together but why the need to handle packets when sending? Did I read the article wrong? It's my understanding that the beginsend function is asynchronous so it won't lock up the app when sending something really huge. A followup question, what determines optimal packet size? I can understand that sending a massive amoount of tiny packets would cause unnecessary processing on the other end, correct? Thanks - Mark

Please forgive the length, I'm trying to be detailed as possible. Before I start, because of the flexibility and me being a massive control freak, please don't suggest me using the TCPclient class. I have a massive need to know exactly how my data is being handled. Also, since it's a comparitively difficult class, it's very good practice in networking logic. Thanks :) I'm working on a very low level socket class. My goal is to make it use packets by using a length field to determine when packets are fully received. Having this happen at such a low level removes the need for it in referring applications and the like and allows me to optimize the low level socket without having to redo any of those apps. I've devised many ways of buffering on the receiving end of the class. I'll go over a sending question in a different post :). Here is the basic idea i've come up with. Using the beginreceive routine, data is pumped into tempbuffer() from the start. The very first thing received is a segment with the length field prepended to it. Now, since the length is a fixed size of the 4 byte int32, i just read the first 4 bytes, then... This is where I start to run into ease of code/performance issues. What I'd like to do is create a memorystream and set the capacity with this length. I've thought about everytime I receive a peice of data, I check to see how much is needed then copy to the stream up to that length then start a new packet whenever needed. Unfortunately, since you can no longer set the lower bound of an array, the code starts getting confusing when working with lengths and upper bounds. So, the easiest and extremely understandable way of filling the stream is to go byte by byte in tempbuffer() and add it to the stream. After each byte, check to see if it is full. I'm wondering, since theoretically this class should be able to handle a large amount of receives goin on asyncronously, would this constant loop degrade performance? What sounds like the optimal way of doing this? One last thing, I'd like this socket to be able to handle everything from a simple chat program, to a file transfer (i've pretty much got a way of doing this w/o the above system) to a MMOG. So, any suggestions of a better way is much appreciated. Anything except a delimiter system is acceptable, I've never trusted delimiters to be 100% accurate. Thanks for even reading this! - Mark

bump. It's a good question that I'd like to hear answered as well. :) - Mark

Thanks for the grammatically interesting reply. :) I got the jist though. The receiving buffer is 2 parts, the one read into by vb when receiving data, and a second used to wait for a full line of information. That's very helpful. Many examples use streams but I never really looked into them. I'll take a look now though. Another follow up question. What would happen if the buffer is set to large? To small? I believe the to small is obvious. There would be a large amount of processing on many many packets. Thanks again - Mark

Thank you for your replies. I'm well aware of the TcpClient class. But working directly with the sockets offers me more control in thinks such as encryption, security and all that. It's nice to know exactly how my data is being handled. Again thanks a lot. - Mark

<alliteration>Buffers are baffling to me.</alliteration> I understand the concept of buffers. You put data into a buffer, send it to the recipient, that data goes into a buffer, the data is read from it. Now then, it's rather difficult to explain my question. I know how to use buffers, but I'd like to know more. :D I've read countless articles on vb.net networking, most by microsoft, but some questions remain. Here are some specific questions maybe someone can answer for me. Why does the buffersize matter? If the size is to large, will vb attempt to send all of the data at once or split it up? I've heard reccommended buffer sizes of about 2K up to even 32K ! If data is split up at all when transfering, when vb says i've received data, is it all of the data that the client originally sent, or just what it's received so far? In microsoft's example of a chat app, the receiver waited for a line feed before processing. However, I couldn't tell if the sender was manually splitting up these chunks or if it sent the whole line using send, then vb split the data up. Hopefully you can see what area of buffering I have some confusion about by these two questions. Basically, I'd like to know all of what vb.net is doing behind the scenes when I'm sending and receiving. Please, answers to these specific questions along with any resources would be greatly appreciated. Thanks - Mark

My sincere apologies if this is a repeat post but the search limitations on < 4 char words makes it difficult. Also, forgive the length, I want to make sure I ask the question correctly the first time. Anyway, my questions is this. I know a lot about networking as I've taken many cisco classes and have made several net apps. I know it is designed to be very reliable and efficient. It uses windows and confirmations to make sure every thing has been received. However, I've heard many times from many resources that TCP isn't 100% guaranteed. Packets are not always received in order, are often strung together or are not received at all. Now that's only what I've heard. I've made a few networking apps back in VB6 using winsock and never had these problems, however, that was on a very stable connection and sending very small packages. Now I want to move onto something a bit better. I'm trying to develop a low-level socket class that offers very efficient and near perfect transfers of data, no matter the size. I want to be sure that all packets are received if it's a file of several gigabytes, but also act very fast if there are many small packets coming from different connections. To sum up all of that into a simple question. Should I take the time to implement a more guaranteed transfer using packet ids, lengths, crc, all of that (basically that's a whole different protocol!), or should I trust that tcp will get me all of the information? If the former is the case and to be sure i'd have to make my own custom protocol, couldn't i just use UDP and put that protocol over top of it? I know there is probably no way to guarantee 100% of the time all data will make it perfectly, but > 95% is good to me. Thanks - Mark