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 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.
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 ?
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
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.
I use VB .NET 2022. Currently developing StudyX educational software, PlazSales POS system and Yargis a space ship shooter game.
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
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.
Last edited by rex64; Apr 1st, 2013 at 08:49 AM.
I use VB .NET 2022. Currently developing StudyX educational software, PlazSales POS system and Yargis a space ship shooter game.
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
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
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)?
I use VB .NET 2022. Currently developing StudyX educational software, PlazSales POS system and Yargis a space ship shooter game.
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.
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.
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber