Do not display the end-of-line after the HTTP reply, for instance when
a page is moved.
UDP isn't really useable with large packets because of sockets
limitations and the lack of workaround code.
If a Web page is empty, echoping will display meaningless messages.
Since echoping writes everything to the server, then begins to read
the reply, some echo servers will timeout if you send very long
messages, because they expect you to start to read right now.
Make FLUSH a configure-able option. It would be useful for driving
echoping from a GUI application, for instance. Code does exist but
untested and probably broken.
---------------------------------
New protocols (all with a configure option to enable/disable them
since most of them would require an external library)
* DNS (dig performs some of the functions of echoping but not all: it
does not set the return code, it cannot repeat a query, etc)
* whois
* LDAP
* PostgreSQL
---------------------------------
Long-term wishes (will need much more work):
Following a suggestion from Tobias Oetiker : the remaining thing is
parallel operation ... analog to fping, this would be great as it
would increasse the performance of eechoping greatly ... This would
require changing echoping and creating a loop around select().
Adding support for a new protocol (say, DNS, with BIND's library),
requires changing too many things. echoping needs a plug-in API, so we
can write the new cde outside of echoping and dlopen() it.
------------------------------------
Compiler's warnings:
Tru64's cc:
cc -DHAVE_CONFIG_H -I. -I. -I. -D_POSIX_PII_SOCKET -g -c icp.c
cc: Warning: icp.c, line 92: In this statement, the referenced type of the pointer value "(int ...)0" is "int", which is not compatible with "unsigned long". (ptrmismatch)
Stephane Bortzmeyer
17 years ago