* IRCObject handles all aspects of an IRC connection. In almost all * cases, you will want to override this class and implement just the * callback methods specified in [IRCObject(Callbacks)] to handle * everything. *
** A lot of arguments may not contain spaces. The general procedure on * processing these arguments is that the method will cut the string * off at the first space and use the part of the string before the space * and fail only if that string is still invalid. Try to avoid * passing strings with spaces as the arguments to the methods * that warn not to. *
*/ @interface IRCObject : LineObject { NSString *nick; BOOL connected; NSString *userName; NSString *realName; NSString *password; NSString *errorString; NSStringEncoding defaultEncoding; NSMapTable *targetToEncoding; NSMutableDictionary *targetToOriginalTarget; SEL lowercasingSelector; } /** *NetException if the
* class follows neither protocol. After connecting anObject,
* it will begin to receive the methods designated by its respective
* protocol. anObject should only be connected with this
* after its transport is set.
*/
- connectObject: anObject;
/**
* * Removes anObject from the runloop and releases it. * anObject will no longer receive messages outlined by * its protocol. Does not close the descriptor of * anObject. anObject will receive * a [(NetObject)-connectionLost] message or a [(NetPort)-connectionLost] * message. *
** If any object should lose its connection, this will * automatically be called with that object as its argument. *
*/ - disconnectObject: anObject; /** * Calls -disconnectObject: on every object currently in the runloop. */ - closeEverything; /** * Return an array of all net objects currently being handled by netclasses */ - (NSArray *)netObjectArray; /** * Return an array of all port objects currently being handled by netclasses */ - (NSArray *)portArray; @end #endif netclasses-1.1.0/Source/NetBase.m 0000644 0001750 0000144 00000025330 12503215220 016050 0 ustar multix users /*************************************************************************** NetBase.m ------------------- begin : Fri Nov 2 01:19:16 UTC 2001 copyright : (C) 2005 by Andrew Ruder email : aeruder@ksu.edu ***************************************************************************/ /*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU Lesser General Public License as * * published by the Free Software Foundation; either version 2.1 of the * * License or (at your option) any later version. * * * ***************************************************************************/ /** *NetclassesErrorAborted
*/
- (void)abortConnection;
/**
* Cleans up the connection placeholder. This will release the transport.
*/
- (void)connectionLost;
/**
* Sets up the connection placeolder. If the net object conforms to
* [(TCPConnecting)], it will receive a
* [(TCPConnecting)-connectingStarted:] with the instance of TCPConnecting
* as an argument.
*/
- connectionEstablished: (id * Much of the information presented in this document is based off * of information presented in RFC 1459 (Oikarinen and Reed 1999). * This document is NOT aimed at reproducing the information in the RFC, * and the RFC should still always be consulted for various server-related * replies to messages and proper format of the arguments. In short, if you * are doing a serious project dealing with IRC, even with the use of * netclasses, RFC 1459 is indispensable. *
*/ #import "NetBase.h" #import "NetTCP.h" #import "IRCObject.h" #importWhile netclasses is primarily for asynchronous connections, it can somewhat easily be used for synchronous connections as well.
This is primarily done by directly calling the -[id<NetTransport> writeData:] and -[id<NetTransport> readData:] methods on the appropriate transport. This must be done while the object is not being handled by NetApplication.
The first thing to worry about is that the object is not being handled asynchronously by NetApplication. To ensure that this is the case, -[NetApplication disconnectObject:] should be called with the object we are interested in as the argument. This will remove it from the netclasses runloop. At this point, the object is ready to be written to and read from synchronously.
After disabling asynchronous mode, you can easily write any data you want to the transport using the -[id<NetTransport> writeData:] method with a NSData as the argument. However, none of the data is actually written out. To force the write out of the data, pass a 'nil' argument to -[id<NetTransport> writeData:]. To see if there is more data, use the -[id<NetTransport> isDoneWriting] method on the transport.
After disabling asynchronous mode, you can easily read data from the transport using the -[id<NetTransport> readData:] method. This method takes a single argument of the maximum number of bytes to read. Passing 0 will cause as much data as is available to be read.
This will hopefully explain the basic idea of creating a simple program with netclasses. In this file, I will take you through the creation of a simple server that echos all the data it receives back to the source.
The first thing we need to do is create a class that will handle the connections. This class will need to implement the NetObject protocol.
Here is the interface for this class:
These methods are all callback methods. NetApplication will call these when appropriate. So now we just need to fill these in.
The first method is connectionEstablished:. This method needs to retain the transport given to it. The transport is an object that actually handles the transportation of the data. In most cases, this method will also need to connect the object to the netclasses NetApplication system.
The next method is dataReceived:. This will be called when new data is received, and the argument will hold the actual data received. In our program, we will want to write this data back to the transport immediately.
The next method we need to implement is transport. This one is pretty simple; just return the transport given to us in connectionEstablished:
Last but not least is connectionLost. This method will be called when the connection is lost. This can happen in three ways. First, an error could have occurred on the socket and it had to be closed. The second, the other side can simply have closed its side. The third, is quite simply that someone called [[NetApplication sharedInstance] disconnectObject:] on it.
And that is it for our object! Now let's set up the port to handle the creating of these objects.
Ok, we got our class all set up, so now we are going to setup a port that will receive connections and initialize EchoServ objects (created in Step 1) when new connections are received.
This is a pretty simple task (like everything in netclasses). Ok, let's write up the function and explain it.
Ok, TCPPort is the class used to create a port handling connections on the TCP/IP protocol. initOnPort: takes the port number that you'd like to handle. If the port is 0, it will automatically find an empty port and bind itself to that.
Now we want to set the TCPPort we created to automatically create our class EchoServ when new connections are received. So:
Ok, since we have no idea what port this has been created on, we better print that out. And after that we are done with the port, so we can go ahead and release it and return. When you create a TCPPort, it automatically connects itself with NetApplication, so don't worry about the object actually being deallocated.
Ok, and that is all there is to creating the port! Now onto step 3.
Ok, we've got our server object created and we've got the port ready to receive connections. What do we need to do now? Let's make it go!
Sorry to disappoint you! But that's it! netclasses will automatically handle any and all connections while the runloop is running. The runloop is a pretty integral part of just about any cocoa application (if you make a GUI program, the runloop is basically always going). Feel free to type up this program and compile it and test that it works! It does! In fact, this very program is almost exactly the same thing as the EchoServ example distributed with the standard netclasses distribution.
In conclusion, netclasses is very simple to use and quite usable for small applications and works well on large ones as well. The asynchronous design means that you don't have to worry about threads or any of the little details that you usually have to worry about on networking applications. Its easy to learn, easy to use, and can be used in a variety of applications. Enjoy!
netclasses is an easy to use, unbloated API for handling asynchronous connections in Objective-C under GNUstep as well as OS X. It can also be used for synchronous connections but this is -not- its primary use.
Please also refer to RFC 1459 as a supplement to the IRC portion of this documentation.