On Apr 28, 2006, at 2:12 PM, Cove Schneider wrote:
As far as I can tell fwrite() will occasionally write short. I'm
assuming because my pipe is "backed up" and libpcap can't write
anymore data to it (though I would expect it to block in that case,
so I'm not really sure what's causing it to temporarily write short
data).
Either
1) the pipe is or other network connection is in non-blocking mode
(in which case it *won't* block in that case)
or
2) there's a bug in the OS on which you're running this.
Is there any plan to change this behavior? It would be useful to
me if it retried and wrote out the rest of the data.
Is there any plan to change your setup not to use non-blocking
sockets, or is there any plan by the supplier of your OS to cause
blocking sockets on your system not to behave like non-blocking
sockets (if that's the OS bug) or to cause the standard I/O library's
"fwrite()" on your system to keep writing until everything's written
out or an I/O error occurs? I don't know.
Is there any plan to change *libpcap* to retry? No, as that's not
its job - that's either write's job or fwrite's job.
Is there any plan to add a new API to let you write to a
pcap_dumper_t and get an indication of whether that write got an
error? Yes, although that won't be usable as a callback for pcap_loop
() or pcap_dispatch(), as there's no provision for a callback
returning an error indication.
It would probably be useful to lots of other code on your system,
too, if write() or fwrite() (whichever of those is at fault here, if
the pipe or network connection is in blocking mode), so, if that's
what's happening, you should complain to your OS supplier about this.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
