Server Help

ASSS Custom Projects - TCP/IP over Java

Smong - Wed Feb 26, 2003 4:40 pm
Post subject: TCP/IP over Java
MGB EDIT: Split from Chatnut Client


Will you be releasing the source code?
(I've been working with bridge.dll and it has a similar protocol, but TCP is so much more complicated than UDP in Java since it's a stream and not a packet.)
Grelminar - Wed Feb 26, 2003 7:50 pm
Post subject:
TCP is hard in Java?! I specifically made it simple text over TCP so that it's easy to deal with. Just make a BufferedReader from an InputStreamReader from the socket input stream and call readLine() on it, then use String.split (the two-arg version, so you can specify a limit). Easy. Requires 1.4.1, but that's been out for a while.

Ok, I made both protocols use the same arena name limitations.

I'm not sure what you mean by "team" vs. "freq" chats. Do you mean your own team vs. an enemy team? I wasn't sure which way to go on that.. I think the current way (having them be the same) in the protocol makes the protocol and server simple but might require additional work on the client. But it's really not very much more work, so I think I'm going to keep it.

The protocol, or at least the current impl. certainly needs more work, though: private freqs aren't currently hidden, and I don't think the server supports chat clients changing freq at all. All the ideas I've heard for how to handle private freqs sound hacky to me, so I'm in favor of not handling them. That is, all freq numbers get sent as they are, and everyone knows all freq numbers. Don't worry; this isn't as bad as it sounds: The freqowners module already allows people to kick unwanted people off of their priv freqs, and I'd like to write a password-protected freq system eventually so unwanted people can't even get on in the first place. Comments appreciated on all this.
Dr Brain - Wed Feb 26, 2003 10:46 pm
Post subject:
Grelminar wrote:
TCP is hard in Java?! I specifically made it simple text over TCP so that it's easy to deal with. Just make a BufferedReader from an InputStreamReader from the socket input stream and call readLine() on it, then use String.split (the two-arg version, so you can specify a limit). Easy. Requires 1.4.1, but that's been out for a while.

The Connection was REALLY easy. Smong, what do you mean? Are you afraid of streams or something?

Quote:

Ok, I made both protocols use the same arena name limitations.

Ok, good


Quote:

I'm not sure what you mean by "team" vs. "freq" chats. Do you mean your own team vs. an enemy team? I wasn't sure which way to go on that.. I think the current way (having them be the same) in the protocol makes the protocol and server simple but might require additional work on the client. But it's really not very much more work, so I think I'm going to keep it.

Ok, just a suggestion.

Quote:

The protocol, or at least the current impl. certainly needs more work, though: private freqs aren't currently hidden, and I don't think the server supports chat clients changing freq at all. All the ideas I've heard for how to handle private freqs sound hacky to me, so I'm in favor of not handling them. That is, all freq numbers get sent as they are, and everyone knows all freq numbers. Don't worry; this isn't as bad as it sounds: The freqowners module already allows people to kick unwanted people off of their priv freqs, and I'd like to write a password-protected freq system eventually so unwanted people can't even get on in the first place. Comments appreciated on all this.

There are several things that don't work. Ship status updates are never sent...
Smong - Thu Feb 27, 2003 1:13 pm
Post subject:
Grelminar wrote:
Requires 1.4.1

bleh, how big is the download for windows?

I went here http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html and added to the example making a bridge.dll communicator. After giving up with the BufferedReader and readLine() (the connection just ignored me after the first message) I opted for InputStream and read() in an attempt to handle cluster messages, but this came with its own problems, e.g. after so many messages have been received I get an array overflow even though I told it to write to the beginning of the array!!

Example cluster message:
Code: Show/Hide

TEAM:Smong:A1> Attach to defendTEAM:Smong:A1> Attach to attackARENA:Gotcha..


Overflow problem: (after 1024 chars have been received, of course)
Code: Show/Hide

byte[] dataB = new byte[1024];
...
recv.read(dataB, len, newLen); //recv is the InputStream
...
data = new String(dataB, 0, newLen);

Dr Brain - Thu Feb 27, 2003 4:40 pm
Post subject:
Ok, im afraid I didn't look that hard at your code, but instead Im posting my ChatConnection class for you to adapt, shoudn't be too hard, just remove the chat specific functions and add your own.

BTW: Single line {s are a lot easier to read, but whatever floats your boat...


I realize that this isn't great code ATM, the intface should really be a Vector of interfaces, and the ChatConnection class should really extend a super Connection class.
Smong - Tue Mar 04, 2003 5:33 pm
Post subject:
By adapting my bridge.dll communicator for Chatnet succesfully I've come to the conclusion that bridge.dll uses some different code to ASSS which makes it not work with Java's readLine() (at least 1.3.1 anyway).
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group