[Winpcap-users] pcap_open_offline() vs pcap_fopen_offline()

[Guy Harris]

On Mar 5, 2010, at 5:10 AM, Selçuk Cevher wrote:

> In my previous post, I reported a crash caused by pcap_next_ex().
> 
> Even though I haven't fully confirmed that yet, I suspect that the first argument passed to pcap_next_ex() (i.e. pcap_t *p) might be NULL.

If it is, there's a bug in your program.

> Based on my readings so far, pcap_next_ex() does not return any error value or throws an exception when its first argument is NULL (Still, I need your confirmation).

Correct.  You're not supposed to pass it a null pointer.  When you call pcap_open_live(), or pcap_create(), or pcap_open_offline(), you're supposed to check whether you get a null pointer back, and report an error to the user (or log it to a log file, if your program isn't run by a user) if you get a null pointer back.

> My question is: What happens if I call pcap_open_offline() sequentially for a certain number of times greater than the OS limit on simultaneously open file handles ?
> (I think that it will simply return NULL)

If you run out of open file handles, yes, it will return null, and the error buffer you passed it will get a string in it that says something such as "{file name}: Too many open files" (where {file name} is the file name you passed to pcap_open_offline()).

> To realize such a scenario, pcap_fopen_offline() should be used instead, I think.

You will need one open file descriptor for each file you have open at the same time.  pcap_fopen_offline() just means you have to open the file before you call libpcap; it will *NOT* prevent you from running out of file descriptors.

If you're trying to process all the files in parallel, so that they're all open at the same time, you're going to be constrained by the OS limitations on open files.  There's no way to work around that if you're running into the system's limit on open files; if you're running into the per-process limit on open files, you could try running multiple instances of the program.