> Yes, it's a bit unfortunate that the sort comparison is only using the data
> displayed in the columns for it's sort. Is it possible for the comparison
> routine to obtain the original IP address
Unfortunately, not at present.
BTW, one problem with sorting by the data in the columns is that it
requires the data in the columns to be quickly available, and one
problem with that is that it requires a whole bunch of strings to be
allocated for every single row in the display.
*Currently*, we use a GtkCList for that part of the display, and it
allocates copies of all the column data.
I suspect this uses a *lot* of memory when you read in a large capture
file, takes a significant amount of CPU time to allocate and copy, and
takes a significant amount of time to free when you close the capture
file.
In the future, I'd *really* like to replace the GtkCList with something
that calls a callback procedure to get the column data; done right, this
could:
1) make it easier to add, remove, and move columns on the fly;
2) reduce the memory and CPU requirements.
It would, however, make sorting more complicated.
It might be that the right thing to do is to still allocate per-frame
data corresponding to the stuff in the columns, but *not* to allocate it
as strings (and not to allocate it as separate items for each column of
each row, but to allocate memory in bulk and parcel it out from those
bulk allocations; this might speed up allocation and freeing, and might
also reduce the memory requirements, as the memory-allocator overhead
would be amortized over a large number of units).
In this particular case, the time stamp columns would be generated on
the fly from stuff in the "frame_data" structure, the protocol column
might be a pointer to a string rather than a copy of a string, and the
addresses might be "address" structures with copies of the address data
attached to them, rather than strings, and the "Info" column might still
stored as a string.
I think that would still allow reasonably fast sorting.
> or should it just attempt to read
> a dotted quad and convert that to a 32 bit number if successful ?
What if it's *not* successful? The address columns aren't necessarily
IPv4 addresses; how should the sort work if dealing with more than one
type of address? Should it sort first on address type, and then on
value if the two addresses have the same type? (The scheme I detail
above might make this easier, as the "address" structure contains both
type, length, and data pointer.)