icmp_dev-0.1.2.zip
- 20010922 - 13k
|
|
What is ICMP ?
ICMP is a protocol which can conceptually be placed above IP but which
in fact is part of it. That's because IP uses it to transmit maintenance
information and error reports like: unreachable host, incorrect
parameter, ... If you want to know more about ICMP read the RFC 792. In this
context reading the RFC
791 about the IP protocol is probably a good idea.
What is icmp_dev for ?
The operating system is not the only one allowed to send ICMP
packets. You can do so too in your programs. Normally you would use RAW
sockets for that purpose but the Winsock does not support RAW sockets. As
a replacement Microsoft created "icmp.dll" which provides a
specific API for sending ICMP packets. Of course this is unofficial and
undocumented... except in icmp_dev. icmp_dev provides the needed headers
and libraries for Intel, Alpha, MIPS (R.I.P.) and PowerPC
(R.I.P.)
Well, I must admit that the icmp_dev headers and libraries seem to
originate from Microsoft. Also the Winsocks 2.0 and above support RAW
sockets. But currently only NT 4.0 has it.
What can I do with ICMP?
ICMP is typically used in tools like ping, traceroute or bing. For
example ping sends ICMP Echo Request packets and expects to receive in
return ICMP Echo Reply packets or another type of ICMP packet indicating
an error. It would not be possible to write a tool like ping without ICMP
packets. ICMP is also used in other applications less tied to it. Squid
for instance (a very good Web cache) uses it to determine its
network environment caracteristics and then optimise its behavior
accordingly.
|
ping_src-0.1.4.zip
- 20010922 - 24k
ping_win32_i386-0.1.4.zip
- 20010922 - 33k
|
|
Readme -
Man page
This ping tool is a good example of a tool using the icmp_dev
library described above but it's also much maore than a mere sample
application.
- First it conforms to the Linux ping tool which means that it
supports the fairly standard set of command line options introduced by the
first ping on BSD. Thus you will find many options that are missing from
Microsoft's ping tool. For instance, these options allow you to keep a
temporary link from being shut by sending an ICMP packet every two minute.
The command "ping -i 120 remote.host" will do just that.
- Then it also provides RTT measurements that are more precise than
those of Microsoft's ping. The accuracy obtained is in the microseconds
order instead of the milliseconds. The statistics are also more complete.
Furthermore, you can also use this ping tool as a traceroute tool
using the "-t" option. With this option you can even gather
complete statistics for the RTT to each host on the route.
- Finally I'm quite sure you will find many other uses for this ping
tool. As usual ping_src contains the sources and ping_win32_i386 the
documentation and executable for Intel platforms.
If you plan on compiling ping yourself don't forget to take the
icmp_dev package.
|
bing_src-1.0.4.tar.gz
- 19970603 - 26k
bing_src-1.1.3.tar.gz
- 19970603 - 38k
bing_win32_i386-1.1.3.zip
- 19970603 - 49k
|
|
Readme First - Readme - Man page
What is bing ?
bing is an application written by Pierre Beyssac which measures the
RAW bandwidth of a remote network link. Let me ad some precisions. By
"remote" I mean a link not directly connected to your computer.
For instance you can measure the bandwidth of a link between you ISP and
the rest of the internet. By "RAW" I mean that you can measure
the intrisic bandwidth of the link not what's left once the other users
have taken their share. So even if a link is saturated and you can only
get 1KBps out of it bing will be able to tell you whether it is a 128Kbps
link or 256Kbps or more. Now don't expect miracles. You will not be able
to measure the bandwidth of an ethernet link in a remote end of the
internet through your modem at a time when the internet is completely
saturated.
How does bing work ?
bing uses ICMP of course ! bing sends Echo Request packets of
different sizes and analyses the resulting RTT change. RTT vary a lot from
one measure to the other so bing has to make multiple measures each being
measured as accurately as possible and then it takes the minimum RTT for
each host and packet size. For more information on bing have a look at
the Readme file.
Which file should I download ?
There are two versions of the source. The version 1.0.4 is the latest
stable official release which was developped by Pierre Beyssac but
it only runs on Unix. The version 1.1.3 is a derived development release
which I ported to Wind32 platforms. Eventhough this is a developpement
release I think it is stable enough to be used instead of the 1.0.4
release. For the users of the 1.1.2 release on Win32 I really recommend
the upgrade to this 1.1.3 release as I greatly improved the precision of
the RTT measurements.
|
bing_src-1.3.5.tar.gz
- 19991025 - 79k
|
|
Bing 1.3 is supposed to be a reimplementation from scratch of bing but
for now it just a bunch of code thrown together and you can consider
yourself lucky it it goes as far as compiling. Nethertheless you are
welcome to take it and hack it.
Why reimplementing bing from scratch ?
By reimplementing bing from scratch I hope to rearchitecture so that I
can add new functionalities which I feel would be difficult to implement
in the original version. These functionalities are the following:
- First, instead of using only two packet sizes, bing 1.3 uses many
packet sizes and performs a linear regression on (RTT,size). This should
allow it, via the correlation ratio, to determine when we have know the
RTTs with enough precision to have a good estimate of the badwidth.
Reciprocally this should tell us which RTTs are not know with enough
precision and thus to which machines we should send more probes.
- The second goal is to introduce more ways to mesure the RTT. For
instance some routers block ICMP packets but we could circumvent this by
using the ECHO port. Another very interesting option is to use techniques
that will elicit return packets of a fixed size.
- By combining two RTT mesure methods, one with return packets of a
fixed size and one with return packets of variable size, we can
independantly determine the bandwidth of the uplink and the downlink. What
the point ? More and more links have an asymetric bandwidth: X2/56K/V90
modems, various kinds of DSL, some cable modems, ... The "classic" bing is
unable to mesure the bandwidth of such links.
- Another extension is to "simultaneously" mesure the bandwidth of all the
links leading from one host to another. One advantage of doing it in one
invocation of bing rather than many is that you need to send fewer packets
and also that you should thus get your results faster.
- Last but not least, a goal of this new architecture is to be extensible,
and that at many levels: scheduling of the probes, RTT mesure techinques,
user interface graphical or textual... For instance it is clear that some
interesting mesure scheduling algorithms will not yield their results in
the link order, i.e. link1, then link2, then link3, ... These algorithms
will be best served by a graphical user interface or by a curses based
textual interface.
|
su_src-0.1.0.zip
- 19970603 - 3k
su_win32_i386-0.1.0.zip
- 19970603 - 15k
|
|
This su tools aims to provide the same functionality as on Unix. It
should match the needs of the Windows NT users who want to start a new
shell or application under a new identity.
Unfortunately Windows NT is not multi-user so su is far from working as
well as its Unix counterpart. You will be able to start console and
graphical (but then beware of NT bugs) applications but you will
not get the environment variables of the new user, you will not be able
to access his user registry section (HKEY_CURRENT_USER still points
to the old user), the mounted network drives are still those of the
original user and you will have to share them...
|
I worked on these
programs back in the time when I was porting this huge Unix application to
Windows NT and windows 95. This was a client/server application with
(fortunately) very little graphics. This gave me the opportunity to delve
into the details of the differences between the Unix and the Win32 system
interfaces. It also because of this experience that I ported these
applications from Unix to Windows.