Stuck... Networking (TCPObject)
by Shane Burke · in Torque Game Engine · 01/31/2010 (1:12 am) · 4 replies
I ran into Torque a few weeks ago and decided to use to learn a few things about coding a server. I am however having an issue (not the first since I began but one that I'm not sure of the answer as I don't know enough about Torque or Sockets in general to be quite honest.).
I'm not sure if my problem is with Torque's source (which I can't see), Socket connections in general, or my source...
On my end I currently have code that allows a Torque Client to connect to it Using TCPObject it is able to recieve packets from TCPObject and has some base packet handling code but the problem is I can't send a packet back to the client from the server application....
When I try to send a packet to Torque I use the NetworkStream.Write method if I then use NetworkStream.Close every packet I wrote to the network stream will be sent to Torque but I want it to send each packet as I write them to the network stream because once I use NetworkStream.Close it also closes the socket connection between Torque and my server...
What I think might be going on
A. function TCPObject::Online is programmed on the backend to not process the data on the networkstream until the socket connection is closed.
B. I'm an Idiot and there's another way to send data from my server to Torque.
C. It's normal to have to constantly close and reopen the socket connection to each client when sending individual files. (I really hope this isn't the case... I could code it but whoever designed it this way is an idiot.)
Any input, suggestions, or info no matter how relevant is appreciated I can use all the help I can get thanks in advance.
I'm not sure if my problem is with Torque's source (which I can't see), Socket connections in general, or my source...
On my end I currently have code that allows a Torque Client to connect to it Using TCPObject it is able to recieve packets from TCPObject and has some base packet handling code but the problem is I can't send a packet back to the client from the server application....
When I try to send a packet to Torque I use the NetworkStream.Write method if I then use NetworkStream.Close every packet I wrote to the network stream will be sent to Torque but I want it to send each packet as I write them to the network stream because once I use NetworkStream.Close it also closes the socket connection between Torque and my server...
What I think might be going on
A. function TCPObject::Online is programmed on the backend to not process the data on the networkstream until the socket connection is closed.
B. I'm an Idiot and there's another way to send data from my server to Torque.
C. It's normal to have to constantly close and reopen the socket connection to each client when sending individual files. (I really hope this isn't the case... I could code it but whoever designed it this way is an idiot.)
Any input, suggestions, or info no matter how relevant is appreciated I can use all the help I can get thanks in advance.
#2
I tried altering my code to send that end of line character in many different forms but it still doesn't seem to be working...
I'm sending my stream from VisualBasic.Net I've tried googling to see if vb.net handled end of line characters different but couldn't find anything at all even irrelevant data on it.
Is it the server that needs the end of line to know to send the stream or the client that needs the end of line to know to act on the stream because it's complete?
The code I have as I understand it breaks my string down into binary before it sends it... I would imagine that's normal though and the client should automatically change it back as all data is binary anyways.
Dim responseString As String = "TEST \r\n"
Dim sendBytes As [Byte]() = Encoding.ASCII.GetBytes(responseString)
networkStream.Write(sendBytes, 0, sendBytes.Length)
because of sendBytes.Length I'm assuming it uses the length as the end of line to tell it to send but then even with the end of line on the string im sending the client isn't picking it up.
Is it just not possible to use 3rd party software to communicate with TCPObject?
01/31/2010 (10:53 pm)
Thank you for your response.I tried altering my code to send that end of line character in many different forms but it still doesn't seem to be working...
I'm sending my stream from VisualBasic.Net I've tried googling to see if vb.net handled end of line characters different but couldn't find anything at all even irrelevant data on it.
Is it the server that needs the end of line to know to send the stream or the client that needs the end of line to know to act on the stream because it's complete?
The code I have as I understand it breaks my string down into binary before it sends it... I would imagine that's normal though and the client should automatically change it back as all data is binary anyways.
Dim responseString As String = "TEST \r\n"
Dim sendBytes As [Byte]() = Encoding.ASCII.GetBytes(responseString)
networkStream.Write(sendBytes, 0, sendBytes.Length)
because of sendBytes.Length I'm assuming it uses the length as the end of line to tell it to send but then even with the end of line on the string im sending the client isn't picking it up.
Is it just not possible to use 3rd party software to communicate with TCPObject?
#3
Dim responseString As String = "TEST " + Constants.vbCrLf
You can tell if the client is receiving the data by putting a breakpoint in the function TCPObject::onReceive in tcpObject.cc. It's most likely a bug in your vb.net code because TCPObject does work.
02/01/2010 (2:43 am)
IIRC VB does not use escape characters. Try:Dim responseString As String = "TEST " + Constants.vbCrLf
You can tell if the client is receiving the data by putting a breakpoint in the function TCPObject::onReceive in tcpObject.cc. It's most likely a bug in your vb.net code because TCPObject does work.
#4
02/01/2010 (12:48 pm)
Thank you Wes, I wish I had asked here sooner would have saved me half a week of frustration. Adding the constant.vbCrLf fixed my issue now I can move on to something other than reading MSDN all day. Though I did learn alot from reading so I guess all is well that ends well. 
Torque Owner Wes Macdonald
You need some way to delineate packets. TCP is a stream protocol, that means you could send two strings of data at two different times and they could appear to the client as one long string. Or you could send one long string and it appears on the other end as two strings. You need to indicate end of packet somehow.
If you're using the text based TCPObject interface and are awaiting the onLine callback you will need to terminate your lines with an end of line character. Otherwise it will wait until it receives an end of line or the connection closes.
To transfer binary, you will need to derive a C++ class from TCPObject to do it, you will need to define another way of ending your packets. One way is sending a packet header with the size then follow it with the payload. TCP is a guaranteed protocol so you can safely assume the payload will arrive correctly so long as there are no bugs in your code.