VB .NET Networking Class

[rex64]

I am having issues with my data being chopped (I am missing the tail). Also, I am receiving extra data. I have a few questions (actually a lot).

Do you recommend any great pre-made networking classes for .NET?
We are considering XBOX 360 Networking, and it looks like you need to use their special framework for that, any recommendations here?
Is it normal for sends to be combined?
Is it normal to for receives to be combined?
Is it normal to receive part of the data?
What happens if the sendBuffer overflows, do you loose data?
What happens if the receiveBuffer overflows, do you loose data?
Does data normally get lost during transmission?
Do you ever receive extra data?
Is it ok to just keep sleeping and looping and waiting for data? I am considering making this a different thread that will timeout if it does not receive data after a while.
Is there a way to detect a damaged network stream?
Is there a good way to repair a network stream?
Are there any bytes that cause issues when sending?

I am continuing my work on this networking class. Here is a diagram of the class on post 24, thanks for Niya's help!
http://www.vbforums.com/showthread.p...=1#post4284033

[circuits2]

I don't know if you can accomplish all of the things required by your questions using VB.NET. You would have to use a native language such as C or Assembly. Buffers and Data Streams are managed at Layer 4 of the OSI Model. VB.NET works at a higher layer. Therefore, you simply get what TCP gives you. If you need to actively manage the stream, then you need a lower level language.

[rex64]

I am planning on just using a byte array to re-assemble the data as it arrives. As long as no data is lost or messed up, it should work I believe?

[rex64]

I read this MSDN document but it still does not seem to match the behavior we are experiencing.
http://msdn.microsoft.com/en-us/library/w93yy28a.aspx

The answers to some of my questions from post 1 would be very helpful. Should this thread be moved to the VB .NET networking forum?

[Niya]

Sorry I took so long to get to this. There was a nation-wide blackout and after it passed, I had severe catching up to do on a project.

So what is the problem you're having in a nutshell....lost data I presume ? What application layer protocol are you using for communication ? Is is your own or a common one like HTTP ?

[rex64]

I am planning on improving my Sockets networking class. TCP. I am creating a back-end generic class that can be re-used in other games and applications.

[Niya]

So I take it you're writing your own protocols ?

[rex64]

I think so. We are using the Sockets TCP IP class from the last post and improving it to resolve a few bugs. Can you ask the question in more detail? We plan on letting sockets do the tough work, but we will have our own game commands (protocols) that will basically be XML type of strings.

[rex64]

Is there a way to check the socket send buffer and make sure it is not full before sending? What happens if the buffer is full?

[Niya]

Probably, but I don't know the way because it is unnecessary for me to know. You're not supposed to worry about the send buffer. I think you misunderstand the way you're expected to use sockets with the TCP/IP protocol. TCP is a streaming protocol but your posts implies that you're thinking about it like a message oriented protocol with clear boundaries. When writing TCP/IP applications you must operate under the assumption that you're NEVER going to receive data the same way it was sent. If the remote machine sent three discrete blocks of information, it is entirely normal to receive all of them in one receive call or ten receive calls. TCP/IP treats data as one continuous stream without specific boundaries.

Now obviously that presents the problem of identifying what is being sent. This is why every protocol under the sun either has some kind of length field preceding the data or some kind of marker that helps to identify discrete blocks of data in the stream.

For example, I have a file download system that consists of a client app and a server app. They use TCP/IP to transfer files. What I do is send a header first for every file. There are two important fields in the header. The header length and the file length. The header length tells the receiving application just how many bytes after the length field belongs to the header. This way it doesn't matter how the header is received. It could be received in 1 receive call or 5. The file length field tells me how many bytes after the header belongs to the file. Again, because of that I know exactly how many bytes to write into the file. This is how you're supposed to use TCP/IP. TCP/IP only guarantees that bytes would arrive in the same order that they were sent but not in the same divisions.

Eg. One send call could send the bytes:-
Send 1: 66, 76, 12, 78, 66, 255, 12, 0, 23

But it could be received like:-
Receive 1: 66, 76
Receive 2: 12, 78, 66, 255
Receive 3: 12
Receive 4: 0, 23

It could also be sent:-
Send 1: 66, 76, 12
Send 2: 78, 66
Send 3: 255, 12, 0, 23

And received:-
Receive 1: 66, 76, 12, 78, 66
Receive 2: 255,12
Receive 3: 0, 23

The order is preserved but not the boundaries. Get it now ?

[rex64]

Yes, that helps. I was asking about the send because sometimes it seems like we may be overloading the buffer and then I am wondering if data gets corrupted (partial data sent)?

[Niya]

Well don't do anything silly like trying to send a 500 MB array. If you have anything that large to send, send it in pieces.

I am wondering if data gets corrupted (partial data sent)?

It won't. TCP guarantees that everything you sent gets delivered. If anything bad should happen, like the sender being disconnected, Winsock would throw an exception hence you would and can never receive corrupted data and if no exceptions are thrown during a Winsock session, you would always receive all the data that was sent and in the order it was sent. This is the guarantee that the TCP part of TCP/IP provides. That is why its the most dominant network protocol on Earth.