Server Help :: View topic - What is the chatnet protocol?

Server Help

ASSS Questions - What is the chatnet protocol?

Smithy101 - Sat Jun 19, 2004 11:37 pm
Post subject: What is the chatnet protocol?

What exactly is the chatnet protocol?

CypherJF - Sat Jun 19, 2004 11:46 pm
Post subject:

Its the protocol for chatting w/ ASSS servers... ASCII and TCP, making it very easy for anyone to program a client.

Smithy101 - Sat Jun 19, 2004 11:49 pm
Post subject:

Ah! I think i get it

CypherJF - Sat Jun 19, 2004 11:51 pm
Post subject:

basically, chatnet allows you to make an eq. to subchat w/ subgame servers.. chatnet only applies to ASSS (may be known as 'AS3')

Smithy101 - Sat Jun 19, 2004 11:53 pm
Post subject:

Oh im starting to understand this more now.

Cyan~Fire - Sun Jun 20, 2004 11:09 am
Post subject:

Cyph wrote:

ASCII and TCP, making it very easy for anyone to program a client.

I personally prefer a packet, I mean, what's easier than filling in a struct? Computers aren't designed to work with strings, they're designed to work with numbers.

D1st0rt - Sun Jun 20, 2004 2:45 pm
Post subject:

You could have a string of numbers

Mr Ekted - Sun Jun 20, 2004 3:49 pm
Post subject:

Cyan~Fire wrote:

[..]

I personally prefer a packet, I mean, what's easier than filling in a struct? Computers aren't designed to work with strings, they're designed to work with numbers.

Using TCP makes the connection into a stream; there are no packets, and no need for the app to handle reliability. Just send your data bytes--they don't have to be text--and they will be received in the order sent. This makes a lot of sense for something like a chat protocol (eg IRC).

Mine GO BOOM - Sun Jun 20, 2004 5:38 pm
Post subject:

Some programming languages, such as java/php/perl, handle TCP/IP protocols like this very well. So for them, its much easier to do this type of connection than setting up a whole UDP reliable handler.

CypherJF - Sun Jun 20, 2004 9:49 pm
Post subject:

This would be ideal for VB users, that cant do structs nicely...

Mr Ekted - Sun Jun 20, 2004 10:21 pm
Post subject:

Perhaps you misunderstand. TCP is not text. TCP can contain exactly the same information as UDP. The difference is the delivery mechanism...

UDP: A sends data XYZ to B. XYZ is transmitted as a packet. B receives a packet with XYZ, or he doesn't. Either way, nothing else is transmitted. Example...

Code: Show/Hide

A sends AAA, then BBBB, then CCCCC.
Network sends packet AAA.
Network sends packet BBBB.
Network sends packet CCCCC.
B receives packet AAA.
B receives packet CCCCC.
B never knows about packet BBBB.

TCP: A sends data XYZ to B. Internally, the TCP stack may send XYZ as a single packet, or as 2 packets XY and Z, or as 3, whatever. Each packet gets a sequential id. When B receives a given packet from A, his TCP stack sends back an acknowledgement of which packet was received. A will re-send unacknowledged packets until they are ack'd or until some timeout period, at which time the connection is closed. On B's side, the packets are stored inside the TCP stack until they can be presented to the application in the order sent. Example...

Code: Show/Hide

A sends AAA, then BBBB, then CCCCC.
Network sends packet AA.
B receives packet AA. Acks it. AA data passed to application.
Network sends packet ABBBBC.
Network sends packet CCC.
Network sends packet C.
B receives packet CCC. Acks it.
Network resends packet ABBBBC.
B receives packet ABBBBC. Acks it. ABBBBCCCC data passed to application.
B receives packet C. Acks it. C data passed to application.
A never receives ack for packet C.
Network resends packet C.
B receives packet C. Acks it again. Ignores data since that id already processed.

Mine GO BOOM - Mon Jun 21, 2004 1:54 am
Post subject:

Since Ekted did a very good job explaining the technical aspect of the differences between UDP and TCP, I'll explain the reasoning behind which is better when.

If you are working with data that needs to be reliable, and always in the correct order, TCP will implement this for you. You can pump out the data as fast as you like, and the protocol will handle controlling the speed for you. This is very useful for file transfering, such as how the whole HTTP/FTP works.

If you need speed, and can safely withstand losing some information, then UDP is good. This is very useful when dealing with something that needs to be updated in real time. If you are looking at a stock ticker, and its set to update every second, if you happen to loose one second's worth of data, it won't matter. And if it happens to be delayed and recieved after another, newer updated information, the display doesn't need to show that delayed data. You only care about whats happening right now. The same can be said for games like Subspace, where real-time is important.

So what is the Chat Protocol using TCP? If Bob says "Whats happening" and Jill responds "Not much," if you saw that in reverse order, you would be confused. But if you had to wait a second or two after they typed that message insteading of attempting to get it exactly as they type it, you wouldn't be at a loss, since it is critical information. A few seconds of delay is well worth the cost of losing information, or having it shown out of order.

Sure, you could do reliable handling with UDP, but all you are doing is recreating the wheel. TCP is already created for a reason: its there to help you out when your data, all 100% of it, needs to be accurate and in the correct order at the expense of a little bit of time delay.

Mr Ekted - Mon Jun 21, 2004 2:53 am
Post subject:

The other difference is that since UDP is "one send = one receive", the packet length is handled for you. When you receive a message (which equals one packet), you know it was a complete message fom the sender. In TCP, you either must send the length of the each message with the data, have the length be implied by the message type, or else you are just sending one large block (eg file transfer) where you don't care about the length (or know it in advance). This is all at the application level (send/recv). Examples:

UDP

Code: Show/Hide

Send AAA, BBB, CCC, DDD, EEE
Recv AAA, BBB, CCC, DDD, EEE

One message sent = one packet sent = one packet received = one message received.

TCP

Code: Show/Hide

Send AAA, BBB, CCC, DDD, EEE
Recv A, AAB, BBCCCD, D, DEEE

No relationship between blocks of data or packets sent and blocks of data or packets received. If you need to know message lengths, you can add them to your protocol:

Code: Show/Hide

Send 3AAA, 3BBB, 3CCC, 3DDD, 3EEE
Recv 3A, AA3B, BB3CCC3D, D, D3EEE

And the application must buffer data, extract the message length, then wait for that many bytes before handling it. Note that these examples are only ASCII for convenience. Any binary data is fine (and usually prefered).

Cyan~Fire - Mon Jun 21, 2004 11:58 am
Post subject:

Woohoo thanks for explaining things... even though I knew most of the stuff already.

What I was trying to say (which I muddled with by using the word packet), was that I'd prefer it if chatnet was binary data. Then instead of something like

Code: Show/Hide

char *token = strtok(message, ":\n");
if (strcmp(token, "SEND") == 0)
{
strtok(NULL, ":\n"
if (strcmp(token, "PUB") == 0)
//and so on...
}

you could do something like

Code: Show/Hide

switch (id)
{
case ID_send:
{
   int type = //something....
   switch (type)
   {
      case TYPE_pub:
      //etc
   }
}
}

It just seems cleaner to me... even though it's much less newbie-readable.

Mr Ekted - Mon Jun 21, 2004 2:59 pm
Post subject:

Most common internet protocols (SMTP, POP, HTTP, FTP control, NNTP, etc) are text, which I think is stupid. I'll give in for Telnet.

Mr Ekted - Mon Jun 21, 2004 7:15 pm
Post subject:

Another difference is that a server using UDP can send/recv packets from all clients using a single socket. There is no notion of a connection in the UDP header. It's just source port, destination port, length, and checksum. A packet is a packet.

In TCP, a server must have a socket to listen for incoming connections, then create a new socket for each of those connections. The TCP header has lots of fields to support a real connection: source port, destination port, sequence #, ack #, a bunch of control flags, checksum, etc. This means when you want to check for incoming data, you need to check ALL open sockets every time. This is typically done using select(), but this function is arguably the worst part of the network API design to come from the Berkeley standard.

D1st0rt - Thu Jun 24, 2004 9:49 pm
Post subject:

Heh, tried it out, made a client that can enter an arena in about 5 minutes. Its so easy, Qndre could do it (One would hope

)

CypherJF - Thu Jun 24, 2004 10:14 pm
Post subject:

Yeah I know, I was able to do it as well.. badda bing

Smithy101 - Sun Jun 27, 2004 11:21 am
Post subject:

I think Mr Ekted likes explaining this

Mr Ekted - Sun Jun 27, 2004 2:08 pm
Post subject:

Smithy101 wrote:

I think Mr Ekted likes explaining this

I like to teach, but only if I think learning will take place, which doesn't explain why I argue with Qndre all the time...

Smong - Tue Jun 29, 2004 3:07 pm
Post subject:

I just remembered I am mod in this forum so I deleted some of the junkier posts.

Edit: I've split the replies and locked this. You can find the rest here
http://forums.minegoboom.com/viewtopic.php?t=3003