--- event.3 2004-05-29 15:58:45.000000000 +0100 +++ event.3 2004-06-18 14:35:39.000000000 +0100 @@ -51,12 +51,12 @@ The event module implements a simple threading core that allows a process to wait for multiple I/O and/or timer events. Multiple I/O streams and timers can be monitored simultaneously. Events are delivered via callback -routines provided by the application. When requesting an event, application +routines provided by the application. When requesting an event, the application provides private context that is passed back to the callback routine when the routine is executed, together with some more information about the event. .PP There are two main types of events recognized by the module, and two types -of callback routines are defined: I/O events, i.e. when a filedescriptor +of callback routines are defined: I/O events, i.e. when a file descriptor becomes readable or writable, and timer events, which gets executed once at a given time (specified as an offset from current time). Timers have millisecond resolution. @@ -68,21 +68,21 @@ .PP There are several sets of routines provided by the module, for the following tasks: initialisation, adding/modifying/removing I/O watchers -(keyed by a filedescriptor), adding/removing timers, and performing +(keyed by a file descriptor), adding/removing timers, and performing actual event waiting and dispatching. The following subsections -describes each group of routines in turn. +describe each group of routines in turn. .SS Initialisation .PP Every routine in this module requires an \fIevent context\fR -of type \fIstruct ev_ct\fR (opaquie to the application), that -holds internal state of the module, to be passed as a first -argument \fIet\fR. This argument may be NULL pointer, in which +of type \fIstruct ev_ct\fR (opaque to the application), that +holds the internal state of the module, to be passed as a first +argument \fIet\fR. This argument may be a NULL pointer, in which case a default event context is used (which should be initialized too). This way, it is possible to use several "contexts", or instances, of the module (for example when an application itself -is multi-threaded, with it's own event context in every thread). +is multi-threaded, with its own event context in every thread). To initialize and free event context, the following routines are provided: .PP @@ -91,27 +91,27 @@ int \fBev_init\fR(int \fImaxfdhint\fR, int \fItypeflags\fR) .fi .RS -creates and initializes new event context \- either specific, -or global default that will be used when no context is provided -(when \fIct\fR argument for other routines described below is NULL). -One of this routines (or both, to initialize either as many specific -or single global context) should be called before any other routine +creates and initializes a new event context \- either specific, +or global defaults that will be used when no context is provided +(when \fIct\fR argument for the other routines described below is NULL). +One of these routines (or both, to initialize either as many specific +or a single global context) should be called before any other routine in this module. .PP -\fBev_ct_new\fR() return either pointer to newly allocated +\fBev_ct_new\fR() return either a pointer to newly allocated and initialized event context, or NULL in case of error; \fBev_init\fR() -return 0 on success or negative value on error. In case of error, global +returns 0 on success or a negative value on error. In case of error, global variable \fIerrno\fR will hold specific error information. .PP -Parameter \fImaxfdhint\fR specifies maximum filedescriptor that -application expects to monitor (only as a hint, to allocate enouth +Parameter \fImaxfdhint\fR specifies the maximum file descriptor that +application expects to monitor (only as a hint, to allocate enough resources in one go instead of reallocating new memory on demand). -If \fImaxfdhint\fR is <= 0, the module will determine maximum number -of files a process may open, using \fBev_fdlimit\fR() routine (see below). +If \fImaxfdhint\fR <= 0, the module will determine the maximum number +of files a process may open, using the \fBev_fdlimit\fR() routine (see below). .PP The \fItypeflags\fR parameter (a bitmask) specifies which underlying method -the module should use for event monitoring. Module will choose the "best" -method that matches \fItypeflags\fR from ones which are available on a +the module should use for event monitoring. The module will choose the "best" +method that matches \fItypeflags\fR from ones that are available on a given system. \fItypeflags\fR may be 0, in which case any method may be used. Currently, the following methods are recognized (some are platform-specific): @@ -122,17 +122,17 @@ .IP \fBEV_DEVPOLL\fR /dev/poll interface with \fBioctl\fR(), available on Solaris. .IP \fBEV_POLL\fR -traditional \fBpoll\fR(2) interface, problematic to use when number of -filedescriptors being monitored is large. +traditional \fBpoll\fR(2) interface, problematic to use when the number of +file descriptors being monitored is large. .IP \fBEV_SELECT\fR traditional \fRselect\fR(2) interface, most portable, also problematic -when number of filedescriptors is large, and usually have upper limit -of 1024 filedescriptors (which may be avoided on some systems). +when the number of file descriptors is large, and usually has an upper limit +of 1024 file descriptors (which may be avoided on some systems). .IP \fBEV_ADVANCED\fR -a shortcut for all the more "advanced" methods, the module will choose +a shortcut for all the more "advanced" methods; the module will choose one available on a given platform if any. .PP -Another way to specify which method to use is to set \fB$EV_METHOD\fR +Another way to specify which method to use is to set the \fB$EV_METHOD\fR environment variable to one of the following values: epoll, kqueue, devpoll, poll, select. .PP @@ -149,13 +149,13 @@ void \fBev_free\fR(void) .fi .RS -deallocates resources assotiated with the given specific event context +deallocates resources associated with the given specific event context \fIct\fR or global default context. Calling \fBev_ct_free\fR() with NULL \fIct\fR argument is the same as calling \fBev_free\fR(). Note that -these routines does \fInot\fR close opened files or frees timer structures -which may be assotiated with the event context, this is the responsibility -of an application. Usually, freeing an event context that still have some -timers or I/O watchers assotiated with it is an error. +these routines do \fInot\fR close opened files or free timer structures +that may be associated with the event context, this is the responsibility +of an application. Usually, freeing an event context that still has some +timers or I/O watchers associated with it is an error. .RE .PP .nf @@ -163,7 +163,7 @@ const char *\fBev_method_name\fR(const struct ev_ct *\fIct\fR) .fi .RS -return the code (described near \fBev_init\fR() above) or name of underlying +returns the code (described near \fBev_init\fR() above) or name of the underlying operating system mechanism used for monitoring. .RE .PP @@ -171,28 +171,28 @@ int \fBev_fdlimit\fR(void) .fi .RS -return number of filedescriptors a process may open, according to +returns the number of file descriptors a process may open, according to \fBgetrlimit\fR(2) system call. .RE .SS "Monitoring I/O availability" .PP -The module may monitor a set of filedescriptors and call +The module may monitor a set of file descriptors and call an application\-supplied callback routine (of type \fBev_io_cbck_f\fR) -when a filedescriptor becomes readable, writable or have an -exceptional condition. An application registers a filedescriptor +when a file descriptor becomes readable, writable or has an +exceptional condition. An application registers a file descriptor to be monitored, together with a set of conditions of interest, -a pointer to callback routine and a pointer to application-specific -data. When any of conditions becomes available, module will -execute callback routine, passing it the data pointer, a bitmask -indicating which conditions become true, and a filedescriptor in question, -together with a pointer to assotiated event context. +a pointer to a callback routine and a pointer to application-specific +data. When any of the conditions becomes true, the module will +execute the callback routine, passing it the data pointer, a bitmask +indicating which conditions became true, and a file descriptor in question, +together with a pointer to the associated event context. Available conditions are: .IP \fBEV_IN\fR -filedescriptor is readable (there's some input data to be read), or for +file descriptor is readable (there's some input data to be read), or for end of file. .IP \fBEV_OUT\fR -filedescriptor is writable, usually for sockets when underlying network stack +file descriptor is writable, usually for sockets when the underlying network stack sent buffered data to a peer and more buffer space become available. .IP \fBEV_PRI\fR there's urgent data to be read. @@ -204,22 +204,22 @@ int \fIfd\fR, struct ev_ct *\fIct\fR) .fi .RS -The type of application-supplied callback routine which will be -called by the module when any of the conditions of interest becomes -true. \fIct\fR is the event context assotiated with the event, -either specific or default but is never NULL. \fIfd\fR is the file +The type of an application-supplied callback routine that will be +called by the module when any of the conditions of interest become +true. \fIct\fR is the event context associated with the event, +either specific or default but never NULL. \fIfd\fR is the file descriptor in question. \fIrevents\fR is a bitmask indicating which -conditions (EV_IN, EV_OUT or EV_PRI) are true for the filedescriptor. +conditions (EV_IN, EV_OUT or EV_PRI) are true for the file descriptor. \fIdata\fR is the application-specific data that was passed to \fBev_io_add\fR() or \fBev_io_mod\fR() (below) when the \fIfd\fR -where registered. +was registered. .PP It is ok to add/remove events from within the callback routine. .PP -Note that C language calling rules allows one to use a routine -that accepts only a subset of arguments. Namely, a routine that +Note that C language calling rules allow one to use a routine +that accepts only a subset of arguments. For example, a routine that expects only one argument, a pointer to application data (e.g. -a structure describing server connection), will act as a callback +a structure describing server connection), can be used as a callback just fine. .RE .PP @@ -228,12 +228,12 @@ ev_io_cbck_f *\fRcbck\fR, void *\fIdata\fR) .fi .RS -Registers the new filedescriptor \fIfd\fR to be monitored for conditions -specified by \fIevents\fR parameter, to call a callback routine -\fIcbck\fR with data \fIdata\fR when any of the conditions becomes true. -Routine return 0 if registration was successeful, or negative value on -error (and sets \fIerrno\fR variable appropriately). It is an error to -register a filedescriptor twice. The following error conditions are +Registers the new file descriptor \fIfd\fR to be monitored for conditions +specified by the \fIevents\fR parameter, to call a callback routine +\fIcbck\fR with data \fIdata\fR when any of the conditions become true. +The routine returns 0 if registration was successful, or a negative value on +error (and sets the \fIerrno\fR variable appropriately). It is an error to +register a file descriptor twice. The following error conditions are possible: .IP EEXIST \fIfd\fR is already registered with a given event context @@ -244,10 +244,10 @@ .IP EINVAL \fIfd\fR is negative .IP EMFILE -\fIfd\fR is too large for underlying monitoring mechanism to handle -(e.g. \fBselect\fR(2) usually unable to work when \fIfd\fR >= 1024) +\fIfd\fR is too large for the underlying monitoring mechanism to handle +(e.g. \fBselect\fR(2) is usually unable to work when \fIfd\fR >= 1024) .IP ENOMEM -there is no memory available to initialize internal structure +there is no memory available to initialize internal structures .IP EFAULT \fIcbck\fR is NULL .RE @@ -257,17 +257,17 @@ ev_io_cbck_f *\fRcbck\fR, void *\fIdata\fR) .fi .RS -Modifies monitoring parameters for already registered filedescriptor \fIfd\fR. -Parameters and return value are the same of \fBev_io_add\fR(). +Modifies the monitoring parameters for already registered file descriptor \fIfd\fR. +Parameters and return value are the same as for \fBev_io_add\fR(). .RE .PP .nf int \fBev_io_del\fR(struct ev_ct *\fIct\fR, int \fIfd\fR) .fi .RS -Deregisters filedescriptor \fIfd\fR and return 0 on success or negative value +Deregisters file descriptor \fIfd\fR and returns 0 on success or a negative value (and sets \fBerrno\fR) on failure. It is ok to deregister already closed -filedescriptor \fIfd\fR. The following error conditions are possible: +file descriptor \fIfd\fR. The following error conditions are possible: .IP ENOENT \fIfd\fR is not registered with this event context. .RE @@ -276,31 +276,31 @@ int \fBev_io_count\fR(const struct ev_ct *\fIct\fR) .fi .RS -return number of filedescriptors currently registered with the given +returns the number of file descriptors currently registered with the given event context \fIct\fR. The number may be used to watch when there's -no filedescriptors to be monitored, as a condition to exit event loop +no file descriptors to be monitored, as a condition to exit an event loop for example. There's no error return. .SS Timers .PP -In addition to I/O events, the module also implements concept of a -\fItimer\fR, which is once-triggering event based on time. Timer +In addition to I/O events, the module also implements the concept of a +\fItimer\fR, which is a once-triggering event based on time. Timer events are delivered by callbacks in a way similar to I/O events. -Unlike I/O events, each timer is assotiated with a structure which -is owned by application and have to be allocated and freed appropriately -(or it may be a part of some larger application structure). When +Unlike I/O events, each timer is associated with a structure that +is owned by the application and has to be allocated and freed appropriately +(or it may be a part of some larger application structure). When a timer event is triggered (i.e. when the module calls the application-supplied callback routine), the timer is already removed from the list of active -timers, and pointer to timer structure is passed to the routine. +timers, and a pointer to the timer structure is passed to the routine. An application may free the storage if it was dynamically allocated, or reuse the timer structure (to implement repeating timers). .PP -Module caches current time to reduce system call overhead, updating it -during initialisation and at each call to \fBev_wait\fR() dispatching +The module caches the current time to reduce system call overhead, updating it +during initialisation and at each call to the \fBev_wait\fR() dispatching routine (below). In most cases this is sufficient, but an application -may update the cached time by calling \fBev_gettime\fR() routine (below). +may update the cached time by calling the \fBev_gettime\fR() routine (below). Cached current time is stored in \fBev_time\fR (of type \fBtime_t\fR, with -secound resolution), and in \fBev_now\fR (of type \fBlong long\fR) global +second resolution), and in \fBev_now\fR (of type \fBlong long\fR) global variables. .PP The following types, routines and variables are provided: @@ -310,14 +310,14 @@ struct ev_tm *\fItmr\fR, struct ev_ct *\fIct\fR) .fi .RS -The type of timer callback routine. When the module calls the timer callback -routine, it passes application\-registered data pointer \fIdata\fR, pointer to -the timer structure \fItmr\fR and assotiated event context \fIct\fR to it. -When the callback routine is executed, the timer in question \fItmr\fR was -already removed from set of active timers and was disassotiated from the -event context, and may be reused or freed by an application as appropriate. +The type of the timer callback routine. When the module calls the timer callback +routine, it passes the application\-registered data pointer \fIdata\fR, the pointer to +the timer structure \fItmr\fR and the associated event context \fIct\fR to it. +When the callback routine is executed, the timer in question \fItmr\fR has +already been removed from the set of active timers and was disassociated from the +event context, which may be reused or freed by an application as appropriate. .PP -It is ok to add/remove events from within the callback routine, and +It is ok to add/remove events from within the callback routine, and the \fItmr\fR structure may be reused to (re\-)add a timer as appropriate. .PP The same note as given for \fBev_io_cbck_f\fR callback applies here @@ -332,8 +332,8 @@ ev_time_t \fBev_gettime\fR(void) .fi .RS -cached current time in secounds (\fBev_time\fR) or millisecounds -(\fBev_now\fR), and routine that updates the cache and return the +cached current time in seconds (\fBev_time\fR) or milliseconds +(\fBev_now\fR), and routine that updates the cache and returns the same value as it has just stored in \fBev_now\fR. Type \fBev_time_t\fR is a 64bit integer (long long). There is no error return. .RE @@ -344,37 +344,37 @@ struct ev_tm *\fItmr\fR, ev_tm_cbck_f *\fIcbck\fR, void *\fIdata\fR) .fi .RS -Registers new timer event to be triggered after \fImstimeout\fR millisecounds -from now (since \fBev_now\fR). When the timer will be triggered, the module -will call the callback \fIcbck\fR with the value \fIdata\fR. Argument -\fItmr\fR may be either NULL, in which case the routine will allocate -new timer structure dynamically and return it upon successeful completion, -or timer structure already allocated by application, in which case it shold +Registers new timer event to be triggered after \fImstimeout\fR milliseconds +from now (since \fBev_now\fR). When the timer is triggered, the module +calls the callback \fIcbck\fR with the value \fIdata\fR. Argument +\fItmr\fR may be either NULL, in which case the routine will allocate a +new timer structure dynamically and return it upon successful completion, +or a timer structure already allocated by the application, in which case it should be initialized to zero, and \fImust not\fR already be registered. -In either case the application is responsible for freeing memory hold by -\fItmr\fR when it will be disassotiated from the event context (either -when the module will execute callback routine or after \fBev_tm_del\fR). -Routine return pointer to the timer structure, or NULL in case of error +In either case the application is responsible for freeing memory held by +\fItmr\fR when it is disassociated from the event context (either +when the module executes the callback routine or after \fBev_tm_del\fR). +The routine returns a pointer to the timer structure, or NULL in case of error (and sets \fBerrno\fR appropriately). .PP -Timer structure is opaque for an application, and should be zero-initialized -on allocation. The only two fields assessible by the applications are: +The timer structure is opaque for an application, and should be zero-initialized +on allocation. The only two fields accessible by the application are: .nf ev_tm_cbck_f *\fIevtm_cbck\fR void *\fIevtm_data\fR .fi -which holds the pointer to the callback routine and the application-supplied -data. Both fields may be modified by application while the timer is -assotiated with an event context, with the exception that \fIevtm_cbck\fR -can not be NULL. +which hold the pointer to the callback routine and the application-supplied +data respectively. Both fields may be modified by the application while the timer is +associated with an event context, with the exception that \fIevtm_cbck\fR +cannot be NULL. .PP -Possible \fBerrno\fR values after call to \fBev_tm_add\fR() are: +Possible \fBerrno\fR values after a call to \fBev_tm_add\fR() are: .IP EFAULT \fIcbck\fR parameter is NULL .IP EINVAL \fImstimeout\fR value is negative .IP ENOMEM -\fItmr\fR is NULL and there is no memory to allocate new structure. +\fItmr\fR is NULL and there is no memory to allocate a new structure. .RE .PP .nf @@ -383,9 +383,9 @@ .fi .RS similar to \fBev_tm_add\fR(), with the difference that this one expects -timeout in secounds instead of millisecounds, and tries to fire all -timers sheduled for the same secound at once (even if they where registered -at different millisecounds). +timeout in seconds instead of milliseconds, and tries to fire all +timers scheduled for the same second at once (even if they were registered +at different milliseconds). .RE .PP .nf @@ -395,10 +395,10 @@ Removes the given timer \fItmr\fR, which should be registered with the event context \fIct\fR by \fBev_tm_add\fR() routine above. As usual, the application owns the \fItmr\fR structure after the call -to this routine. Routine return amount of millisecounds left to -the time when the timer should be triggered (which may be 0), or -negative value on error. In an attempt to remove a timer which -isn't registered (or has been triggered already), routine will +to this routine. The routine returns the amount of milliseconds left to +the time when the timer should be triggered (which may be 0), or a +negative value on error. In an attempt to remove a timer that +isn't registered (or has been triggered already), that routine will indicate error and set \fBerrno\fR to ENOENT. .RE .PP @@ -406,7 +406,7 @@ int \fBev_tm_count\fR(const struct ev_ct *\fIct\fR) .fi .RS -return number of timers registered with a given event context \fIct\fR. +returns the number of timers registered with a given event context \fIct\fR. .RE .PP .nf @@ -415,7 +415,7 @@ .fi .RS return a time when first timer will be triggered (or 0 if no timers are -registered), and amount of millisecounds left to that time (or -1). +registered), and the amount of milliseconds left to that time (or -1). .RE .SS "Event Loop" @@ -427,29 +427,29 @@ .fi .RS one\-shot wait\-and\-dispatch routine. It waits up to \fImstimeout\fR -millisecounds (specify negative value for to wait forever) for registered -events to happen and executes all necessary callback routines, and when -returns. Return value indicates how many I/O events where handled -(i.e. how many filedescriptors where ready), which may be 0 in case -of timeout or a timer expired, or -1 in case of error. If error +milliseconds (specify a negative value to wait forever) for registered +events to happen, executes all necessary callback routines, and then +returns. The return value indicates how many I/O events were handled +(i.e. how many file descriptors were ready), which may be 0 in case +of timeout or a timer expired, or -1 in case of error. If an error occured (typical case is interrupt, in which case \fBerrno\fR will be set to EINTR), \fBev_wait\fR() still executes any pending timers and -updates current time cache. For real event loop, an application should +updates the current time cache. For a real event loop, an application should call this routine repeatedly until some condition (e.g. number of -filedescriptors registered is non-zero) is true. +file descriptors registered is non-zero) is true. .SH "RETURN VALUES" .PP -Most routines in the module return zero or positive integer value in -case of error +Most routines in the module return zero or a positive integer value in +case of error. .SH "SEE ALSO" select(2), poll(2), epoll(4), kqueue(2), poll(7d), gettimeofday(2), time(2). .SH BUGS -The module is using non-standard time representation (\fBev_time_t\fR -type which is currently defined as long long). This may be not portable. -But using any standard types (struct timeval, struct timespec and the +The module is using a non-standard time representation (\fBev_time_t\fR +type, which is currently defined as long long). This may be not portable. +However, using any standard types (struct timeval, struct timespec and the like) complicates code significantly. .SH AUTHOR --- proxycheck.1 2004-05-27 22:22:19.000000000 +0100 +++ proxycheck.1 2004-06-18 15:00:44.000000000 +0100 @@ -12,20 +12,20 @@ .SH DESCRIPTION -\fBproxycheck\fR is a simple open proxy checking tool which is -capable to quickly discovery open proxy servers on many hosts. -It's primary goal is to detect an open proxy server in order -to prevent it's abuse by various "bad guys", mostly spammers. -Having a wide-open proxy service running on a publicaly accessible +\fBproxycheck\fR is a simple open proxy checking tool, which is +capable of quickly discovering open proxy servers on many hosts. +Its primary goal is to detect an open proxy server in order +to prevent its abuse by various "bad guys", mostly spammers. +Having a wide-open proxy service running on a publicly accessible network is a very bad idea nowadays, and \fBproxycheck\fR may -be used to find such system in order to be able to either secure -a system, or to refuse servicing it until it will be secured +be used to find such systems in order to be able to either secure +that system, or to refuse servicing it until it is secured properly. In order to determine if a given host is running an open proxy service, \fBproxycheck\fR tries to connect to a given destination system via a host and perform some actions, trying to talk with the -destination system. If a talk is successeful, \fBproxycheck\fR +destination system. If a talk is successful, \fBproxycheck\fR assumes the proxy service is running and wide-open. \fBproxycheck\fR supports all commonly used proxy protocols, @@ -33,10 +33,10 @@ "telnet"-style proxies. In future, support for more protocols may be added. -Please note that with current number of various trojan horses +Please note that with the current number of various trojan horses cicrulating around, each opening a proxy on a random port, -it is not really enouth to probe for standard (in whatever -reason) ports built into the \fBproxycheck\fR. Instead, it +it is not really enough to probe the standard (for whatever +protocol) ports built into \fBproxycheck\fR. Instead, it is highly recommended to use a list of currently active ports maintained by several people on the 'net. @@ -51,14 +51,14 @@ increase the verbosity level. All debugging messages will go to standard error stream. -.IP "\fB\-d\fR \fIdeshost\fR:\fIdestport\fR (required)" +.IP "\fB\-d\fR \fIdsthost\fR:\fIdstport\fR (required)" try to establish a proxied connection to the given \fIdsthost\fR, port \fIdstport\fR. This option is required. .IP "\fB\-c\fR \fIcheck\fR[:\fIparams\fR] (required)" the "method" \fBproxycheck\fR will use when talking to a destination system to determine if a proxy is open or not. Interpretation of -\fIparams\fR is \fIcheck\fR\-dependant. This option is required. +\fIparams\fR is \fIcheck\fR\-dependent. This option is required. Several methods are available: .RS .IP "\fBchat\fR:\fIsendstr\fR:\fIexpectstr\fR" @@ -71,26 +71,26 @@ \fIprotocol\fR:\fIip-address\fR:\fIportnumber\fR .br .fi -to the remote system. Proxy assumed to be open if \fIexpectstr\fR is +to the remote system. The proxy is assumed to be open if \fIexpectstr\fR is found. .IP "\fBdsbl\fR (no parameters accepted)" -try to submit all found proxies to the DSBL.org\-like system, see +try to submit all found proxies to a DSBL.org\-like system, see http://dsbl.org/ for more details. All the parameters required (username, password, recipient address, cookie server, ...) are expected to be found in environment variables. Run \fBproxycheck\fR with \fB\-h\fR option to see a list of recognized variables and -their default values. By default, \fBproxycheck\fR will anonimously +their default values. By default, \fBproxycheck\fR will anonymously submit all found proxies to unconfirmed.dsbl.org (which isn't very -useful). For trusted DSBL user, at least DSBL_USER and DSBL_PASS +useful). For a trusted DSBL tester, at least the DSBL_USER and DSBL_PASS variables should be set properly. .RE .IP "\fB\-p\fR \fIproto_port_spec\fR" specifies protocol and ports to connect to. If not given, \fBproxycheck\fR -will try it's built-in default list. This option may be specified more +will try its built-in default list. This option may be specified more than once. See below for \fIproto_port_spec\fR. If \fIproto_port_spec\fR is specified for a single host to check, it applies to that host only, -and no protocols/ports in default list will be checked for that host. +and no protocols/ports in the default list will be checked for that host. .IP \fB\-D\fR do not reset default port list when using \fB\-p\fR option, but prepend @@ -102,19 +102,19 @@ and their level, execute \fBproxycheck\fR with \fB\-h\fR option. .IP "\fB\-t\fR \fItimeout\fR" -a timeout, in secounds, for every operation. Default value is 30 secounds. +a timeout, in seconds, for every operation. Default value is 30 seconds. The timer starts at the connection attempt to the proxy itself, after sending the "connect" command to the proxy and so on. .IP "\fB\-m\fR \fImaxconn\fR" Do not attempt to make more than \fImaxconn\fR parallel connections. -By default, maximum number of parallel connections limited by the +By default, the maximum number of parallel connections is limited by the operating system and on most systems it is around 1000. .IP "\fB\-M\fR \fImaxhconn\fR" Do not make more than \fImaxhconn\fR parallel connections to the same host (default is unlimited). This may be useful for overloaded -proxies which can't handle many parallel connections using different +proxies that can't handle many parallel connections using different ports/protocols, but may significantly slow down the whole process. .IP \fB\-s\fR @@ -168,13 +168,13 @@ .SH USAGE Simplest usage of \fBproxycheck\fR is to try to connect to e.g. -your own mailserver with \fBchat\fR check method. First, connect -to your mailserver on port 25 to see which line it outputs upon -connection (SMTP greething line), and use it with \fBchat\fR: +your own mail server with \fBchat\fR check method. First, connect +to your mail server on port 25 to see what line it outputs upon +connection (SMTP greeting line), and use it with \fBchat\fR: .nf proxycheck -d yourmailserver.example.org:25 \\ - -c chat::\fIgreething\fR ip.add.re.ss... + -c chat::\fIgreeting\fR ip.add.re.ss... .fi \fBproxycheck\fR will write a single line for every proto:port @@ -189,29 +189,29 @@ a full list of protocols) and \fI80\fR is a port number where the proxy service is running. -In addition, if \fBproxycheck\fR is able to guess \fIoutgoing\fR IP address +In addition, if \fBproxycheck\fR is able to guess the \fIoutgoing\fR IP address of a proxy as seen by a destination system, and if that address is different -from input \fBproxycheck\fR is connecting to, it will print this information +from the input \fBproxycheck\fR is connecting to, it will print this information too on the same line, like: .br .nf 127.0.0.2 hc:80 open 127.0.0.3 .br .fi -where \fI127.0.0.3\fR is \fIoutgoing\fR IP addres of a multihomed/cascaded -proxy as reported by the destination system. This IP address is hint only, -there is no simple and reliable way currently exists for \fBproxycheck\fR +where \fI127.0.0.3\fR is the \fIoutgoing\fR IP address of a multihomed/cascaded +proxy as reported by the destination system. This IP address is a hint only, +there is no simple and reliable way that currently exists for \fBproxycheck\fR to determine that information. \fBProxycheck\fR is able to parse a line sent by remote system in \fB\-c chat\fR mode \- in this mode, \fBproxycheck\fR skips all printable characters after \fIexpstr\fR it found and searches for -opening `[', when tries to find closing ']' and interpret digits and dots -in between as an IP address which gets printed like above. If your -mailserver's initial reply contains remote system's IP, or if your -mailserver replies with remote system's IP address to HELO/EHLO command, +opening `[', then tries to find a closing ']' and interprets digits and dots +in between as an IP address, which gets printed like above. If your +mail server's initial reply contains remote system's IP, or if your +mail server replies with the remote system's IP address to HELO/EHLO command, this feature may be useful (in the last case, HELO command should be specified in chat). -When \fB\-n\fR option is specified, for proto:ports which aren't running +When \fB\-n\fR option is specified, for proto:ports that aren't running an open proxy service, and for which \fBproxycheck\fR is able to strongly determine this, a line in the following format will be written: .br @@ -219,10 +219,10 @@ 127.0.0.4 hc:80 closed .br .fi -Note however that in most cases there is no way to reliable determine +Note however that in most cases there is no way to reliably determine whenever a given service is \fInot\fR open: for example, an open proxy server may be overloaded and refusing connections. In most -cases, \fBproxycheck\fR assumes proxy is in unknown state, only a +cases, \fBproxycheck\fR assumes the proxy is in unknown state; only a few codes are recognized as real indication of "closed" state. When \fB\-x\fR option is specified, there will be additional proxy info @@ -235,7 +235,7 @@ .br .fi -One may see some detail of \fBproxycheck\fR's operations giving +One may see some detail of \fBproxycheck\fR's operations by giving sufficient number of \fB\-v\fR options in the command line. Verbosity level of 5 (\fB\-vvvvv\fR) will show almost everything. All the debugging output will go to the standard error stream and thus will @@ -245,7 +245,7 @@ .SH "EXIT CODE" \fBproxycheck\fR will exit with code 100 if at least one open proxy server was found. In case of incorrect usage, it will exit -with code 1. If no open proxies where found, \fBproxycheck\fR +with code 1. If no open proxies were found, \fBproxycheck\fR will return 0. .SH LICENSE @@ -254,5 +254,5 @@ .SH AUTHOR \fBproxycheck\fR written by Michael Tokarev . -Latest version of this utlilty may be found at +Latest version of this utility may be found at http://www.corpit.ru/mjt/proxycheck.html. --- proxycheck.c 2004-05-27 22:27:37.000000000 +0100 +++ proxycheck.c 2004-06-18 15:09:55.000000000 +0100 @@ -31,7 +31,7 @@ struct in_addr addr; /* IP address of proxy */ pxyprotoport_t *pps; /* array of proto:ports to test */ pxyprotoport_t *cpp; /* next proto:port to test */ - int nopen; /* numbef of open ports found */ + int nopen; /* number of open ports found */ int nactive; /* number of active connections */ struct pxyhost *next; /* next host to test */ } pxyhost_t; @@ -39,7 +39,7 @@ static char *progname; static int verbose; /* verbosity level */ static int maxconn; /* max number of connections */ -static int maxhconn; /* max number of connection to one host */ +static int maxhconn; /* max number of connections to one host */ static int stopfound; /* stop searching on first open port */ struct sockaddr_in baddr; /* bind address */ static pxyhost_t *hosts; /* host list */ @@ -463,19 +463,19 @@ " (may be used more than once) - see below\n" " -D - do not reset default portlist in case -p option specified\n" " -a - use \"advanced\" protocols too (more -a's means more advanced)\n" -" -t timeout - general timeout in secounds, default %d\n" +" -t timeout - general timeout in seconds, default %d\n" " -m maxconn - maximum number of parallel connections\n" " -M maxhconn - maximum number of parallel connections to one host\n" " -s - stop probing a host after first found open proxy\n" " -b bindaddr - bind to specified address\n" -" -x - print extended info (proxy software etc) if known\n" +" -x - print extended info (proxy software etc.) if known\n" " -n - also print a line about definitely closed proxies\n" "\n" "proto_port_spec is in the form [proto:][port,port,...].\n" "If portlist is omitted, default ports for given protocols\n" "will be tried; if proto is omitted, either all protocols will\n" "be tried (if port is not known), or the protocols which are\n" -"assotiated with this port.\n" +"associated with this port.\n" "\n" "The following protocols are recognized:\n" , progname, progname, pxytimeout / 1000); @@ -687,7 +687,7 @@ /*XXX abort active connections: need a list of * all connections for this host, and a state of * each: in case of e.g. dsbl, connection may be - * in final stage and it isn't a good idea to simple + * in final stage and it isn't a good idea to simply * abort connection in this case. * Here, we just will not do any more *new* connections. */ @@ -1002,7 +1002,7 @@ dstspec = strdup(pxybuf); } - dsbluser = egetenv("DSBL_USER", "anonimous"); + dsbluser = egetenv("DSBL_USER", "anonymous"); dsblpass = egetenv("DSBL_PASS", ""); dsblfrom = egetenv("DSBL_FROM", dsbluser); dsblrcpt = egetenv("DSBL_RCPT", "listme@listme.dsbl.org"); @@ -1040,13 +1040,13 @@ const pxycheck_t checks[] = { { "chat", expecth, expectd, expectw, expecti, ":sendstr:expectstr", "perform a little chat: send `sendstr'\n" - " to the remote system and assume proxy is open is `expectstr'\n" + " to the remote system and assume proxy is open if `expectstr'\n" " is returned. `sendstr' defaults to proto:ip:port\n" }, { "dsbl", dsblh, dsbld, dsble, dsbli, "[:smtpserver[:port]]", "attempt to submit proxy to DSBL-like system\n" " DSBL settings are expected to be in environment:\n" - "\t$DSBL_USER - username (anonimous)\n" + "\t$DSBL_USER - username (anonymous)\n" "\t$DSBL_PASS - password (default is empty)\n" "\t$DSBL_COOKIE_HOST - cookie server (cookie.dsbl.org)\n" "\t$DSBL_COOKIE - already obtained DSBL cookie\n" --- proxylogger.c 2004-05-27 22:27:37.000000000 +0100 +++ proxylogger.c 2004-06-18 15:11:43.000000000 +0100 @@ -1,14 +1,14 @@ /* $Id: proxylogger.c,v 1.4 2004/05/27 21:27:37 mjt Exp $ * A trivial program (should be invoked by inetd) that * writes out a string "550 ESMTP_unwelcome [peer.ip.add.ress]" - * to the network and optionally waits for a string in form + * to the network and optionally waits for a string in the form * [junk]protocol:ip.add.re.ss:port\n * from the remote system. May be used as a destination for * proxycheck program. All connections (together with the * information in the above form, if given) are optionally * logged to a specified file. * Options: - * -n - do not wait for a proxy connection info + * -n - do not wait for proxy connection info * -t timeout - timeout in secs * -l logfile - where to log proxy/connection info * -s say - what to say @@ -36,7 +36,7 @@ struct in_addr pxyaddr; unsigned short pxyport; char *logfile; -char *say = "550 open proxy cheking service"; +char *say = "550 open proxy checking service"; char *saylast = "550 ESMTP_unwelcome"; char buf[2048]; --- pxy.c 2004-05-27 22:22:19.000000000 +0100 +++ pxy.c 2004-06-18 15:16:10.000000000 +0100 @@ -262,7 +262,7 @@ return 1; } else { - pxyinfo(c, 2, "HTTP request successeful (%d)", r); + pxyinfo(c, 2, "HTTP request successful (%d)", r); return 0; } } @@ -274,7 +274,7 @@ * 1 - request sent, want reply */ if (c->pxystate == 0) { - /* some proxies requires \r\n in separate packet - doh */ + /* some proxies require \r\n in separate packet - doh */ if (pxyprintf(c, 3, "CONNECT %s:%d HTTP/1.0\r\n", inet_ntoa(c->dstaddr), c->dstport) && pxywrite(c, "\r\n", 2, 3) && @@ -284,7 +284,7 @@ else /* todo: read headers if any here. * requires some logic change: upper-level protocol - * routines should deal with already read data */ + * routines should deal with already-read data */ pxyaction(c, 0); } @@ -299,7 +299,7 @@ if (!r) return 0; if (r < 0) return 1; /*if (r / 100 == 2)*/ { - pxyinfo(c, 2, "HTTP request successeful (%d)", r); + pxyinfo(c, 2, "HTTP request successful (%d)", r); return 0; } } @@ -560,14 +560,14 @@ } static void fuh(pxyconn_t *c, int UNUSED e) { - /* FTP proxy. Wait for initial FTP greething and + /* FTP proxy. Wait for initial FTP greeting and * issue a command: * USER dummy@targethost:targetport\r\n * After this, target receives * USER dummy * and transparent connection begun. * There is no way to use such proxy with protocols - * dependant on first line from client (e.g. http). + * dependent on first line from client (e.g. http). */ int l; if (!c->pxystate) { --- pxy.h 2004-05-27 22:22:19.000000000 +0100 +++ pxy.h 2004-06-18 15:18:12.000000000 +0100 @@ -37,7 +37,7 @@ const char *aname; /* alternative name */ const char *transport;/* http */ const char *fullname; /* HTTP CONNECT */ - int family; /* internal code: "family" of proto, HTTP, FTP, etc */ + int family; /* internal code: "family" of proto, HTTP, FTP, etc. */ void (*handler)(pxyconn_t *, int); /* protocol handler */ int (*check)(pxyconn_t *c, char *buf, int l); } pxyproto_t; @@ -60,7 +60,7 @@ * handled by hlcbck routine. */ struct pxyconn { - int fd; /* filedescriptor */ + int fd; /* file descriptor */ struct in_addr pxyaddr; /* address of a proxy */ struct in_addr dstaddr; /* address of destination */ ipport_t pxyport; /* port number of a proxy */ @@ -78,13 +78,13 @@ extern int pxytimeout; -/* almost all routines returns > 0 on ok and 0 on error; +/* almost all routines return > 0 on ok and 0 on error; * in error case, pxyaction will be called automatically. */ /* allocate new connection structure */ pxyconn_t *pxynew(); -/* free connection resources, timers etc */ +/* free connection resources, timers etc. */ void pxyfree(pxyconn_t *c); /* start new connection attempt */