Does any documentation exist for TCPObject?

#1 Also, a quick follow-up question...

When using TCPObject.send (which I'm assuming I need to use to send data to my server), how does it send the data? (eg. how can I program my server [written in Delphi] to make sure I received a full "packet" and not an incomplete one?)

#2 TCPObject.send doesn't encapsulate data into packets by default, you'll have to implement that in your protocol on top of it. For example, a really easy way would be to always send with a terminating line break or other character (ex: myConnection.send(%command @ "\n");

That makes it very easy on the server, simply read one line in at a time and process it. If you're going to have newlines on the feed as part of data, either encode the data, or choose another terminator.

#3 Old TCPObject Tutorial

#4 Thanks for the link and information!

The core of my server (again, written in Delphi) is complete but I'm still a bit unsure of how to handle data on the client side (Torque2D side).

From what I've read, any incoming data is processed in a callback function (TCPObject::onLine). All data is returned in a single local variable (%line). Here are my questions...

1) Suppose the data sent from my server (using TCP) gets split up in-route to my client. So instead of my client receiving one call to onLine() it receives two calls to onLine(). Does TCPObject() wait to do the callback until it receives a linebreak character or something?

2) How do I parse out %line? Let's say my server sends this:
MOVE 10 "10 20"

I'd like this to be parsed into 3 parameters (into an array or something). MOVE is the command, 10 is the object to be moved, and the "10 20" is the destination coordinates. "10 20" should NOT be split into two parameters... it should only be one because it is inclused in quotes. Make sense?

Thanks again for any help...

#5 1) Yes. The transport and OS layers (in accordance with the TCP/IP RFC) handle mid-transimssion packet modifications. By the time the data gets to your TCPObject, it is simply broken by line terminators (of course, assuming that your Delphi server is sending them out in line terminator parsed sections).

2) A very common technique is to use getWord()/getWords() to parse the line. You'll need to be able to recognize your "tag", and then know how many parameters to read in for that tag, and where to put them. One common technique for this is a finite state machine that tracks each type of possible tag, and implements the tagged data element's individual fields.

Note that your comment about the quoted section would either require special parsing in your ::onLine(), or if you analyze your data and the way you plan on delivering it, it's un-needed. In your particular example, your protocol basically requires that for every MOVE tag, there will be three data elements sent: ObjectID, Pos.x, and Pos.y. Since your data protocol will implicitly define the logical grouping, your data transmision stream doesn't need the quote symbols, and in fact they are redundant (and therefore taking up valuable bytes in your data stream).

Note: In more complex data protocols such as HL7, one of the standards available for transmitting health care data between dissimilar applications, the concept of quoted data values is used for a special circumstance: to indicate that a particular field should be made empty. This only applies within the data protocols that use both tag based and positional-relative techniques that minimize your data stream for large amounts of data.

#6 1. That's correct, onLine parses on newline, so you won't get a partial line unless maybe the connection closes before the last line is fully sent perhaps, and then you might get the last bit of data received. Then again it may dump that data, I've never tested.

2. You have a variety of options for parsing. I would highly recommend slightly altering your command packing functionality so that tab characters are used to separate data. Then you can use the built-in getField(), setField(), removeField(), getFieldCount() methods which does string parsing on tab characters. So if that string were really "MOVE\t10\t"10 20" (where \t is the esc character for tab) you could do a loop against getFieldCount() to parse out each piece of data.

You could use getWord() directly on your example string (getWord(), getWordCount(), etc. uses spaces instead of tabs) but it would parse the space inside the quotes, which you'd have to handle separately somehow yourself. Better to make your life as easy as possible by designing the command protocol to be clear-cut.


Edit: Stephen's quicker on the draw than I am, ignore my redundancy. :)

#7 @Luke: Hehe..it's just that I had to do exactly this for setting up a protocol between a Java based application that monitored military simulation networked spaces, and get that information into Torque. I used an object that inherited from TCPObject, so I know it can work when thought out well!

Something that you'll have to consider though:

When you receive an object ID, you'll need a way to take the data from the stream, find the object the data is referring to in your simulation, and then apply the modification to the torque object. Not hugely challenging, but can be a bit tricky--especially if the object doesn't currently exist in your client's simulation.

#8 Thanks for the excellent information!

When you say Torque internally buffers data until it receives a linebreak, does that mean chr(13) + chr(10), or does it only need chr(13) OR chr(10)?

Thanks again!!

#9 @Stephen: I use the exact same approach communicating with my backend game server, which is also in Java. And you're right, it works beautifully! :)

@John: Specifically the source searches for \n (chr(10)) but it handles the additional existance of \r (chr(13)) as well. It doesn't appear to handle just chr(13) however.

#10 I'm pretty sure it's chr(13) or the newline character \n however I've never seen it notice the difference between \n\r and \n

@Harold hey man I'm still waiting for you to finish that TCPObject tutorial, I really want to implement my own ingame IRC client to take some of the chat load off the hands of the server. Did you ever finish the IRC client?

#11 BTW, I'm working on an MMO kit for T2D.

Im a-going to include everything you need to make a MMO, including Auto-Update (30% Done), and a sample game (Which will prolly be (c)'d).

I thought people might care. If it works I'll ask GG if they will publish it as an addon for T2D...


--- REASONS TO GET ---


I have implemented a T2D SERVER CONSOLE, plus Packet class so far.... You can write stuff in binary...

Int16, Int32, Int64, Bool, etc... Even 0'd strings.

It has a packet-size and ID, and im even including MD5 code! =P

--- RELEASE DATE ---

Not very soon, but hey.... I thought someone reading this sometime in the future may be interested...
Now back to codeweaver I go...

#12 Thanks for the information...

My game will only need string-based packets but the stuff already included in T2D should work just fine. However, I would like to encrypt my packets somehow (even if it's MD5 encode/decode)...

I'm writing my server in Delphi and it's coming along very nicely (blocking sockets with threading, player database [XML], game rooms, etc).

I would be very interested in your progress though!

#13 LoL

Dreamer... Yes I had a working IRC client for Torque. But it was mostly a re-hacked version of the one that came with Tribes 2. Pretty much what the TGE Lobby Resource was. RL has been very much getting in the way so (not to mention a HD crash that lost most of my work with TGE about 1 1/2 years ago)... Perhapse I'll try to get back to it sometime soon.