Ethereal-users: [Ethereal-users] Problem in compiling ethereal9.7 on HP-UX

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Mudium, Ravi Kumar (Ravi)" <mudium@xxxxxxxxxx>
Date: Wed, 6 Nov 2002 09:25:55 +0530
Hi Guy
I have down loaded ethereal 0.9.7 version and configured the software. When
I tried to compile I found that two files are missing they are 
packet-bacapp.c
packet-q2931.c 

When I look for these files on web at 

http://www.go.dlr.de/fresh/unix/src/misc/.warix/ethereal-0.9.7.tar.gz.html

I found these two files but they have some problem with INCLUDE FILES.
Can some one help me to come out of this problem

Thanks in advance.

Regards
Ravi Kumar 
-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Sent: Tuesday, November 05, 2002 1:00 PM
To: McNutt, Justin M.
Cc: ethereal-users@xxxxxxxxxxxx
Subject: Re: [Ethereal-users] Three big problems


On Wed, Oct 30, 2002 at 09:12:46PM -0600, McNutt, Justin M. wrote:
> 3) I need to be able to use at least 1000 files in the ring buffer
> (although about 60,000 would be much better).

The current ring buffer code keeps all the ring buffer files open, so
the upper limit would be a limit on the number of files a process can
keep open.

I don't know what the highest value to which you can set the "maximum
open files" limit is on a UNIX system, nor do I know what the limit is
on Windows with various versions of MSVC++.  I suspect it's less than
60,000; it might well be less than 1000 on some systems - and, even on
systems where it's more than 1000, the limit on the number of open files
that can be used with the "standard I/O library" routines (fopen,
fclose, fwrite, fseek, and so on), those being the routines used to
write to capture files, might be lower (for example, a hypothetical
former telephone monopoly in a hypothetical large North American country
might have used a single byte for the file descriptor number in the
"FILE" data structure in their hypothetical implementation of UNIX,
and might hypothetically have refused to increase it as said library
might have exported the raw data structure and had macros defined in
<stdio.h> that directly accessed it, and that hypothetical structure
might have been laid out in such a fashion that changing the size of
that field might have broken binary compatibility with programs linked
with shared libraries, which they might hypothetically refused to allow
in releases of their UNIX implementation, which we shall call, for the
sake of argument, "System V").

> So what are the odds that a patch to remove the 10-file ring buffer
> limit could be checked into a nightly build in the near future?

A patch that raises the limit to 1000 or more on *all* platforms would
be a substantial change, thanks to SV's annoying stdio limitations; the
chances that it will be checked in are probably slim at best.

Somebody might contribute a patch to remove the limit checking entirely
(after having checked to make sure that if Ethereal runs into the limit
because the user asked for too many ring buffer files, it reports it and
cleans up properly).  I don't know whether that will happen.  (I won't
be contributing one - I don't have enough time right now to do all the
stuff on *my* TODO list for Ethereal, so I'm unlikely to add other
people's items to it.)
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users