RE: socket trace

> Basically, you open up a socket for reading on a certain port, and
> when you get a connection, you open up an outgoing port and forward
> all the packets you receive.

Although this technique works well for home grown client/server TCP apps, it
gets a little more involved for 3rd party client/server apps.

With home grown stuff, you have a helping hand because you know the protocol
used on the socket, i.e. how packets are formed, length (or terminating
indicators), etc., and can easily set up a middle man to capture traffic.

For 3rd party applications, your life can be/is a little more difficult, as
you don't have the insight of the protocol, unless it's a well known
protocol and you can then go read the RFC to see how to handle the data on
the socket.

If performance is not an issue (and in these circumstances it normally
isn't) using select() and then only recv() 1 byte, logging it, sending it,
then dropping back on the select() works, but you lose the ability to pretty
the output in to packets.

--phil
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---