Server Help

[Smithy101]

What exactly is the chatnet protocol?

[CypherJF]

Its the protocol for chatting w/ ASSS servers... ASCII and TCP, making it very easy for anyone to program a client.
_________________
Performance is often the art of cheating carefully. - James Gosling

[Smithy101]

Ah! I think i get it
_________________
OMG LIEK AEI SPEL GEWD!

[CypherJF]

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

[Smithy101]

Oh im starting to understand this more now.

[Cyan~Fire]

[D1st0rt]

You could have a string of numbers
_________________

[Mr Ekted]

[Mine GO BOOM]

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]

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

[Mr Ekted]

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]

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]

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]

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]

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]

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]

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]

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

[Smithy101]

I think Mr Ekted likes explaining this

[Mr Ekted]

[Smong]

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