Written by yours truely. I'm currently using this in TAHCBot v4. It handles all the streams for you and makes your life a whole hell of a lot easier.
package protocol;
/*
* TAHCBot v4
* Socket Class
* Author: Joe[e2]
*
* This is just a socket wrapper I made to make sockets easier to use
* Methods:
* - bool connect(String, int)
* - bool isConnected()
* - void sendData(String)
* - void sendData(byte[])
* - bool hasData()
* - String getData()
*/
import java.net.*;
import java.io.*;
import ui.*;
public class TAHCSocket {
static Socket sck;
static BufferedReader sck_BR;
static OutputStream sck_OS;
static Console ConsoleUI = new Console();
public static boolean isConnected() {
return sck.isConnected();
}
public String getData() {
try {
return sck_BR.readLine();
}catch(IOException e) {
ConsoleUI.out(4, "Unable to get data. " + e.toString());
return "";
}
}
public boolean hasData() {
try {
if(sck_BR.ready() == true) {
return true;
}else{
return false;
}
}catch(IOException e) {
ConsoleUI.out(2, "IOException thrown by sckBNET_BR.ready(): " + e.toString());
return false;
}
}
public boolean connect(String sHostname, int iPort) {
try {
sck = new Socket(sHostname, iPort);
}catch(IOException e) {
ConsoleUI.out(4, "Socket error: " + e.toString());
return false;
}
makeStreams();
return true;
}
public static void sendData(String data) {
try {
for(int i = 0; i < data.length(); i++) {
sck_OS.write(data.charAt(i));
}
sck_OS.flush();
}catch(IOException e) {
ConsoleUI.out(2, "Error sending data. " + e.toString());
}
}
public static void sendData(byte[] data) {
try {
sck_OS.write(data);
sck_OS.flush();
}catch(IOException e) {
ConsoleUI.out(2, "Error sending data. " + e.toString());
}
}
private static void makeStreams() {
try {
sck_OS = sck.getOutputStream();
sck_BR = new BufferedReader(new InputStreamReader(sck.getInputStream()));
}catch(IOException e) {
ConsoleUI.out(2, "Could not create I/O streams. " + e.toString());
}
ConsoleUI.out(1, "Streams created.");
}
}
Joe wrote something (semi)useful. *grin*
Warrior, you read my mind. B)
Make a function to check if its connected!
You do it!
Quote from: Joe[e2] on November 06, 2005, 10:50:13 PM
You do it!
I don't do Java, nor drink it, and its also YOUR class, not mine.
It's public domain. It's not mine. I typed it, then released it. It belongs to George Bush for all I care.
EDIT -
Added bool isConnected().
EDIT -
Optimized void sendData(String).
Added void sendData(byte[]).
Hmm, I thought Java's socket interface was really easy to use anyway..
Is it just me, or does it never both informing the program if the connection fails?
Quote from: iago on November 07, 2005, 01:59:09 AM
Hmm, I thought Java's socket interface was really easy to use anyway..
Is it just me, or does it never both informing the program if the connection fails?
I don't think that last question is coherent. :P
Quote from: iago on November 07, 2005, 01:59:09 AM
Hmm, I thought Java's socket interface was really easy to use anyway..
Is it just me, or does it never both informing the program if the connection fails?
Changed void connect(String, int) to bool connect(String, int).
EDIT -
Removed Configuration object and config.* import, seeing as how its not used.
NOTE -
ConsoleUI.out(1, String) is a [DEBUG] message.
Quote from: MyndFyrex86] link=topic=3608.msg37051#msg37051 date=1131349966]
Quote from: iago on November 07, 2005, 01:59:09 AM
Hmm, I thought Java's socket interface was really easy to use anyway..
Is it just me, or does it never both informing the program if the connection fails?
I don't think that last question is coherent. :P
Sorry, both = bother. Joe seemed to understand :P
Few suggestions:
1. You may want a disconnect method (sorry if you have one already, and I don't see it).
2. Your data is better off being private, to adhere to concept of encapsulation. It is good that you made your makeStreams() method private, as the user/object will never be using that. Similarly, the user will never be using the first four fields. It is best to keep your data private and have a public interface instead, so that if you have to change your object's data, then these changes will be kept local, since you will already have a set-in-stone interface that other objects know about that will change/access the data.
3. There are ways of designing java programs that minimize the amount of static stuff that you need. From your code I see that parts of your GUI (ConsoleUI) and your socket interface are both static. Using the Model-View-Controller (MVC) design pattern, you can optimize a program's OO'ness. Static stuff smells like global variables, and although it is proven that a program can be written completely "staticly" (as you see in procedural programming), in Java it is best to minimize your use of static stuff. The more OOP a program is, the less work you have to do (hm, well, in theory), and the more flexible it is. This becomes much more evident in very large appplications, like the ones that require a team of programmers.
EDIT
* shrugs at posting 16 days after the last post =p *
Not a problem, bumping a post, because you contributed to it.
TAHCBot (the project this is part of) is sort of suspended right now (its stranded on my other box =p), but when I dig that out again I'll add that stuff.
Thanks Ender.
A few years ago for an IRC project I made something for initializing C sockets. I still use it sometimes. I used it in slackchat ;P I didn't want to paste all of the source on this thread, so I made this pseudo-codish C example of how it's used. If you're interested in the code I posted it at http://www.javaop.com/~tmp/isock.tar.gz.
#include "isock.h"
int main (void) {
//Socket filehandle
int bnetsock;
//Declare main bnet sockaddr_in structure/socket
struct sockaddr_in bnets;
//Declare server/port
char *server = "useast.battle.net";
int port = 6667;
//Create instance of sockaddr_in socket
create_socket (&bnets, &bnetsock, sport, sserver)
//Connect the socket
irc_connect(bnetsock, bnets)
printf("TCP stream initiated on %s:%d.\n", sserver, sport);
send(bnetsock, "\x1", 1, 0);
}
Excuse my Java newb-ey-ness, but what characters are sent after every string, and what characters does readline look for, and are the two the same?
If I tell your socket to write out "test" will it send "test" + ASCII 13, "test" + ASCIII 10, "test" + ASCII 13 + ASCII 10, or something completely different?
If you tell the socket to write "test", it will send "test", nothing more, nothing less.
I'm not really sure how buffered input streams (or whatever I'm using =p) work, but I guess each time it recieves a TCP packet, it adds that packet as a new thing on the buffer, and when you ask for something from the buffer, it returns the first thing and then bumps everything up a notch.
Sorry to bump this, but I found some new use to it. After going through a semester of Java programming, I've decided to fix the way I did some formatting and whatnot, and I made it more generic (it doesn't use my console class, but rather uses System.err for what's necessary).
EDIT -
Whoops -- didn't review it carefully enough. I just remembered that I learned what staticness was in class, and when I wrote this, I was just trying to get around it. Fixed.
package networking;
/*
* Author: Joe[x86]
*
* This is just a socket wrapper I made to make sockets easier to use
* Methods:
* - bool connect(String, int)
* - bool isConnected()
* - void sendData(String)
* - void sendData(byte[])
* - bool hasData()
* - String getData()
*/
import java.net.*;
import java.io.*;
public class SocketWrapper
{
private Socket sck;
private BufferedReader sck_BR;
private OutputStream sck_OS;
public SocketWrapper()
{
}
public SocketWrapper(Socket socket)
{
this.sck = socket;
makeStreams();
}
public boolean isConnected()
{
return sck.isConnected();
}
public String getData() {
try
{
return sck_BR.readLine();
}
catch(IOException e)
{
System.err.println("Socket threw IOException in getData():\n" + e.toString());
return "";
}
}
public boolean hasData()
{
try
{
if(sck_BR.ready() == true)
{
return true;
}
else
{
return false;
}
}
catch(IOException e)
{
System.err.println("Socket threw IOException in hasData():\n" + e.toString());
return false;
}
}
public boolean connect(String hostname, int port)
{
try {
sck = new Socket(hostname, port);
}
catch(IOException e)
{
System.err.println("Socket threw IOException in connect():\n" + e.toString());
return false;
}
return makeStreams(); // this will return true if makeStreams() works
}
public void sendData(String data)
{
try
{
for(int i = 0; i < data.length(); i++)
{
sck_OS.write(data.charAt(i));
}
sck_OS.flush();
}
catch(IOException e)
{
System.err.println("Socket threw IOException in sendData():\n" + e.toString());
}
}
public void sendData(byte[] data)
{
try
{
sck_OS.write(data);
sck_OS.flush();
}
catch(IOException e)
{
System.err.println("Socket threw IOException in sendData():\n" + e.toString());
}
}
private boolean makeStreams()
{
try
{
sck_OS = sck.getOutputStream();
sck_BR = new BufferedReader(new InputStreamReader(sck.getInputStream()));
}
catch(IOException e)
{
System.err.println("Socket threw IOException in makeStreams():\n" + e.toString());
try
{
sck.close();
}
catch(IOException ex)
{
// who cares? If we had an exception, it's closed anyhow. :)
}
return false;
}
return true;
}
}
public SocketWrapper()
{
}
What is the point of that?
Quote from: AntiVirus on January 31, 2007, 11:16:41 AM
What is the point of that?
It's an override of the constructor so you don't have to provide parameters to create a 'SocketWrapper' object. I'm not sure it makes sense considering the other constructor calls private methods, though...
Quote from: AntiVirus on January 31, 2007, 11:16:41 AM
public SocketWrapper()
{
}
What is the point of that?
The connect(String, int) method creates a new Socket object. Creating a SocketWrapper instance with a Socket parameter does not require connect to be called; creating one without a parameter requires connect to be called.
If that constructor wasn't there, he couldn't create a SocketWrapper without a socket parameter.
Quote from: Sidoh on January 31, 2007, 11:41:32 AM
I'm not sure it makes sense considering the other constructor calls private methods, though...
The connect method calls the private method you're referring to.
Quote from: MyndFyrex86] link=topic=3608.msg107620#msg107620 date=1170261819]
The connect method calls the private method you're referring to.
Missed that. Unfortunately, I don't have the patience to sift through Joe's code. :(
Quote from: Sidoh on January 31, 2007, 01:33:03 PM
Quote from: MyndFyrex86] link=topic=3608.msg107620#msg107620 date=1170261819]
The connect method calls the private method you're referring to.
Missed that. Unfortunately, I don't have the patience to sift through Joe's code. :(
I'm not sure if you were trying to insult my code or your patience by saying that, but if you ask me, my code is just about as readable as JavaOp2, which is pretty decent.
And yeah, MyndFyre is correct.. originally I didn't have any constructor at all, but now that I allowed it to be constructed with a Socket object passed, I needed to manually put a no-args constructor in there. When you don't have any constructor at all, Java automagically gives it a no-args constructor.
Quote from: Joex86] link=topic=3608.msg107653#msg107653 date=1170302191]
I'm not sure if you were trying to insult my code or your patience by saying that, but if you ask me, my code is just about as readable as JavaOp2, which is pretty decent.
It'd be obvious if I was trying to insult your code. I'm not trying to insult it; I'm merely saying I don't have the patience to read it.
If I were wanting to read it, i'd probably drop it also. Nothing looks worse to me than code designating an entire line to a single opening french bracket ({).
Quote from: warz on January 31, 2007, 11:59:21 PM
If I were wanting to read it, i'd probably drop it also. Nothing looks worse to me than code designating an entire line to a single opening french bracket ({).
I prefer adding curly brackets (I prefer that name for them :P) after statements as well. Since it's a completely subjective decision, though, I don't think it really matters which way you prefer...
I have an ungodly huge resolution, and I don't like code that looks clumped together. The brainchild of these two factors is the braces getting their line.
And what's the real name for them? To me, ( ) has always been parenthesis, [ ] are brackets, and { } are braces.
Quote from: Joex86] link=topic=3608.msg107697#msg107697 date=1170368815]
I have an ungodly huge resolution, and I don't like code that looks clumped together. The brainchild of these two factors is the braces getting their line.
And what's the real name for them? To me, ( ) has always been parenthesis, [ ] are brackets, and { } are braces.
Every CS professor here refers to them as "curly brackets." I've never heard them called "French Brackets."
Quote from: Joex86] link=topic=3608.msg107697#msg107697 date=1170368815]
I have an ungodly huge resolution, and I don't like code that looks clumped together. The brainchild of these two factors is the braces getting their line.
And what's the real name for them? To me, ( ) has always been parenthesis, [ ] are brackets, and { } are braces.
Those are the names I've used, except () are parenthes
es, and one is a parenthes
is.
Quote from: Sidoh on February 01, 2007, 08:21:25 PM
Quote from: Joex86] link=topic=3608.msg107697#msg107697 date=1170368815]
I have an ungodly huge resolution, and I don't like code that looks clumped together. The brainchild of these two factors is the braces getting their line.
And what's the real name for them? To me, ( ) has always been parenthesis, [ ] are brackets, and { } are braces.
Every CS professor here refers to them as "curly brackets." I've never heard them called "French Brackets."
Ditto!
Yeah, they're generally called curly brackets or braces here, usually braces.
And I greatly prefer putting the opening brace on its own line. I find it makes it easier to match up braces. Also, it keeps code more spaced out which makes it look cleaner. From marking assignments, I can tell you that I, as a marker, greatly prefer it on the next line.
One of my profs was telling me that the on-the-same-line convention was created because of text-books, which have limited space. In the olden days (think Pascal), it had to be on the next line.
But you're right, it's completely subjective. Those are just my opinions. Of course, anybody who doesn't agree with me is very much wrong (kidding, of course :P)
Quote from: iago on February 03, 2007, 12:43:55 PM
One of my profs was telling me that the on-the-same-line convention was created because of text-books, which have limited space. In the olden days (think Pascal), it had to be on the next line.
I thought Pascal used things like "begin" and "end" to delimit code blocks.