Re: VB .NET Networking Class
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.
Re: VB .NET Networking Class
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?
Re: VB .NET Networking Class
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?
Re: VB .NET Networking Class
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 ?
Re: VB .NET Networking Class
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.
Re: VB .NET Networking Class
So I take it you're writing your own protocols ?
Re: VB .NET Networking Class
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.
Re: VB .NET Networking Class
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?
Re: VB .NET Networking Class
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 ?
Re: VB .NET Networking Class
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)?
Re: VB .NET Networking Class
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.
Quote:
Originally Posted by
rex64
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.