Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep
Home >> All >> org >> apache >> commons >> [ net Javadoc ]

Page 1   2  
•org.apache.commons.net.util.* (1)

• org.apache.commons.net: Javadoc index of package org.apache.commons.net.


Package Samples:

• org.apache.commons.net.util

Classes:

• FTPClient: FTPClient encapsulates all the functionality necessary to store and retrieve files from an FTP server. This class takes care of all low level details of interacting with an FTP server and provides a convenient higher level interface. As with all classes derived from org.apache.commons.net.SocketClient , you must first connect to the server with connect 55 before doing anything, and finally disconnect 55 after you're completely finished interacting with the server. Then you need to check the FTP reply code to see if the connection was successful. For example: boolean error = false; try { int reply; ...
• SMTPClient: SMTPClient encapsulates all the functionality necessary to send files through an SMTP server. This class takes care of all low level details of interacting with an SMTP server and provides a convenient higher level interface. As with all classes derived from org.apache.commons.net.SocketClient , you must first connect to the server with connect 55 before doing anything, and finally disconnect 55 after you're completely finished interacting with the server. Then you need to check the SMTP reply code to see if the connection was successful. For example: try { int reply; client.connect("mail.foobar.com"); ...
• FTPClientConfig: This class implements an alternate means of configuring the FTPClient object and also subordinate objects which it uses. Any class implementing the Configurable interface can be configured by this object. In particular this class was designed primarily to support configuration of FTP servers which express file timestamps in formats and languages other than those for the US locale, which although it is the most common is not universal. Unfortunately, nothing in the FTP spec allows this to be determined in an automated way, so manual configuration such as this is necessary. This functionality was ...
• FTP: FTP provides the basic the functionality necessary to implement your own FTP client. It extends org.apache.commons.net.TelnetClient simply because it saves the writing of extra code to handle the FTP control connection which always remains open during an FTP session and uses the Telnet protocol. Aggregation would require writing new wrapper methods and wouldn't leverage the functionality already present in org.apache.commons.net.SocketClient. To derive the full benefits of the FTP class requires some knowledge of the FTP protocol defined in RFC 959. However, there is no reason why you should have ...
• RCommandClient: RCommandClient is very similar to RExecClient , from which it is derived, and implements the rcmd() facility that first appeared in 4.2BSD Unix. rcmd() is the facility used by the rsh (rshell) and other commands to execute a command on another machine from a trusted host without issuing a password. The trust relationship between two machines is established by the contents of a machine's /etc/hosts.equiv file and a user's .rhosts file. These files specify from which hosts and accounts on those hosts rcmd() requests will be accepted. The only additional measure for establishing trust is that all ...
• NNTPClient: NNTPClient encapsulates all the functionality necessary to post and retrieve articles from an NNTP server. As with all classes derived from org.apache.commons.net.SocketClient , you must first connect to the server with connect 55 before doing anything, and finally disconnect() 55 after you're completely finished interacting with the server. Remember that the isAllowedToPost() 55 method is defined in NNTP . You should keep in mind that the NNTP server may choose to prematurely close a connection if the client has been idle for longer than a given time period or if the server is being shutdown by ...
• SMTP: SMTP provides the basic the functionality necessary to implement your own SMTP client. To derive the full benefits of the SMTP class requires some knowledge of the FTP protocol defined in RFC 821. However, there is no reason why you should have to use the SMTP class. The SMTPClient class, derived from SMTP, implements all the functionality required of an SMTP client. The SMTP class is made public to provide access to various SMTP constants and to make it easier for adventurous programmers (or those with special needs) to interact with the SMTP protocol and implement their own clients. A set of ...
• NNTP: The NNTP class is not meant to be used by itself and is provided only so that you may easily implement your own NNTP client if you so desire. If you have no need to perform your own implementation, you should use NNTPClient . The NNTP class is made public to provide access to various NNTP constants and to make it easier for adventurous programmers (or those with special needs) to interact with the NNTP protocol and implement their own clients. A set of methods with names corresponding to the NNTP command names are provided to facilitate this interaction. You should keep in mind that the NNTP server ...
• FTPFileEntryParser: FTPFileEntryParser defines the interface for parsing a single FTP file listing and converting that information into an FTPFile instance. Sometimes you will want to parse unusual listing formats, in which case you would create your own implementation of FTPFileEntryParser and if necessary, subclass FTPFile. Here are some examples showing how to use one of the classes that implement this interface. The first example shows how to get an iterable list of files in which the more expensive FTPFile objects are not created until needed. This is suitable for paged displays. It requires that a parser object ...
• RLoginClient: RLoginClient is very similar to RCommandClient , from which it is derived, and uses the rcmd() facility implemented in RCommandClient to implement the functionality of the rlogin command that first appeared in 4.2BSD Unix. rlogin is a command used to login to a remote machine from a trusted host, sometimes without issuing a password. The trust relationship is the same as described in the documentation for RCommandClient . As with virtually all of the client classes in org.apache.commons.net, this class derives from SocketClient. But it relies on the connection methods defined in RcommandClient ...
• RExecClient: RExecClient implements the rexec() facility that first appeared in 4.2BSD Unix. This class will probably only be of use for connecting to Unix systems and only when the rexecd daemon is configured to run, which is a rarity these days because of the security risks involved. However, rexec() can be very useful for performing administrative tasks on a network behind a firewall. As with virtually all of the client classes in org.apache.commons.net, this class derives from SocketClient, inheriting its connection methods. The way to use RExecClient is to first connect to the server, call the rexec() ...
• VMSFTPEntryParser: This Class uses the FTPEntryParser class to validate the input string. It also requires the NetComponents library version 1.3.7 or later and the OROMatcher library for the regualar expressions stuff. USAGE: Create an instance of VMSFTPEntryParser VMSFTPEntryParser parser = new VMSFTPEntryParser(boolean); True = returns all versions of a file with the respective ;# False = only the last version will return (Default) Create an instance of FTPClient FTPClient FTPClientObj = new FTPClient(); Connect to the NODE FTPClientObj.connect(); Login to the NODE FTPClientObj.login(username,password); Switch ...
• FTPListParseEngine: This class handles the entire process of parsing a listing of file entries from the server. This object defines a two-part parsing mechanism. The first part is comprised of reading the raw input into an internal list of strings. Every item in this list corresponds to an actual file. All extraneous matter emitted by the server will have been removed by the end of this phase. This is accomplished in conjunction with the FTPFileEntryParser associated with this engine, by calling its methods readNextEntry() - which handles the issue of what delimits one entry from another, usually but not always a ...
• OS2FTPEntryParser: This Class uses the ListParser class to validate the input string. It also requires the NetComponents library version 1.3.7 or later and the OROMatcher library for the regualar expressions stuff. USAGE: Create an instance of OS2FTPEntryParser OS2FTPEntryParser parser = new OS2FTPEntryParser(); Create an instance of FTPClient FTPClient FTPClientObj = new FTPClient(); Connect to the NODE FTPClientObj.connect(); Login to the NODE FTPClientObj.login(username,password); Switch directories if you have to FTPClientObj.changeWorkingDirectory(thePath); You might want to check if you are truly in a OS2 System ...
• NTFTPEntryParser: This Class uses the ListParser class to validate the input string. It also requires the NetComponents library version 1.3.7 or later and the OROMatcher library for the regualar expressions stuff. USAGE: Create an instance of NTListParser NTListParser parser = new NTListParser(); Create an instance of FTPClient FTPClient FTPClientObj = new FTPClient(); Connect to the NODE FTPClientObj.connect(); Login to the NODE FTPClientObj.login(username,password); Switch directories if you have to FTPClientObj.changeWorkingDirectory(thePath); You might want to check if you are truly in a NT System String am_I_NT ...
• TFTPClient: The TFTPClient class encapsulates all the aspects of the TFTP protocol necessary to receive and send files through TFTP. It is derived from the TFTP because it is more convenient than using aggregation, and as a result exposes the same set of methods to allow you to deal with the TFTP protocol directly. However, almost every user should only be concerend with the the open() 55 , close() 55 , sendFile() 55 , and receiveFile() 55 methods. Additionally, the setMaxTimeouts() 55 and setDefaultTimeout() 55 methods may be of importance for performance tuning. Details regarding the TFTP protocol and the ...
• CharGenUDPClient: The CharGenUDPClient class is a UDP implementation of a client for the character generator protocol described in RFC 864. It can also be used for Systat (RFC 866), Quote of the Day (RFC 865), and netstat (port 15). All of these protocols involve sending a datagram to the appropriate port, and reading data contained in one or more reply datagrams. The chargen and quote of the day protocols only send one reply datagram containing 512 bytes or less of data. The other protocols may reply with more than one datagram, in which case you must wait for a timeout to determine that all reply datagrams have ...
• DatagramSocketClient: The DatagramSocketClient provides the basic operations that are required of client objects accessing datagram sockets. It is meant to be subclassed to avoid having to rewrite the same code over and over again to open a socket, close a socket, set timeouts, etc. Of special note is the setDatagramSocketFactory 55 method, which allows you to control the type of DatagramSocket the DatagramSocketClient creates for network communications. This is especially useful for adding things like proxy support as well as better support for applets. For example, you could create a DatagramSocketFactory that requests ...
• SocketClient: The SocketClient provides the basic operations that are required of client objects accessing sockets. It is meant to be subclassed to avoid having to rewrite the same code over and over again to open a socket, close a socket, set timeouts, etc. Of special note is the setSocketFactory 55 method, which allows you to control the type of Socket the SocketClient creates for initiating network connections. This is especially useful for adding SSL or proxy support as well as better support for applets. For example, you could create a SocketFactory that requests browser security capabilities before creating ...
• TFTPRequestPacket: An abstract class derived from TFTPPacket definiing a TFTP Request packet type. It is subclassed by the TFTPReadRequestPacket and TFTPWriteRequestPacket classes. Details regarding the TFTP protocol and the format of TFTP packets can be found in RFC 783. But the point of these classes is to keep you from having to worry about the internals. Additionally, only very few people should have to care about any of the TFTPPacket classes or derived classes. Almost all users should only be concerned with the TFTPClient class receiveFile() 55 and sendFile() 55 methods.
• TFTPPacket: TFTPPacket is an abstract class encapsulating the functionality common to the 5 types of TFTP packets. It also provides a static factory method that will create the correct TFTP packet instance from a datagram. This relieves the programmer from having to figure out what kind of TFTP packet is contained in a datagram and create it himself. Details regarding the TFTP protocol and the format of TFTP packets can be found in RFC 783. But the point of these classes is to keep you from having to worry about the internals. Additionally, only very few people should have to care about any of the TFTPPacket ...
• TimeUDPClient: The TimeUDPClient class is a UDP implementation of a client for the Time protocol described in RFC 868. To use the class, merely open a local datagram socket with open 55 and call getTime 55 or getDate 55 to retrieve the time. Then call close 55 to close the connection properly. Unlike TimeTCPClient , successive calls to getTime 55 or getDate 55 are permitted without re-establishing a connection. That is because UDP is a connectionless protocol and the Time protocol is stateless.
• TelnetClient: The TelnetClient class implements the simple network virtual terminal (NVT) for the Telnet protocol according to RFC 854. It does not implement any of the extra Telnet options because it is meant to be used within a Java program providing automated access to Telnet accessible resources. The class can be used by first connecting to a server using the SocketClient connect 55 method. Then an InputStream and OutputStream for sending and receiving data over the Telnet connection can be obtained by using the getInputStream() 55 and getOutputStream() 55 methods. When you finish using the streams, you ...
• CharGenTCPClient: The CharGenTCPClient class is a TCP implementation of a client for the character generator protocol described in RFC 864. It can also be used for Systat (RFC 866), Quote of the Day (RFC 865), and netstat (port 15). All of these protocols involve connecting to the appropriate port, and reading data from an input stream. The chargen protocol actually sends data until the receiving end closes the connection. All of the others send only a fixed amount of data and then close the connection. To use the CharGenTCPClient class, just establish a connection with connect 55 and call getInputStream() 55 to ...
• DaytimeUDPClient: The DaytimeUDPClient class is a UDP implementation of a client for the Daytime protocol described in RFC 867. To use the class, merely open a local datagram socket with open 55 and call getTime 55 to retrieve the daytime string, then call close 55 to close the connection properly. Unlike DaytimeTCPClient , successive calls to getTime 55 are permitted without re-establishing a connection. That is because UDP is a connectionless protocol and the Daytime protocol is stateless.

Home | Contact Us | Privacy Policy | Terms of Service