The tcpdump stuff (based on the jpcap project(s)) doesn't look promising - I've spent a few hours this afternoon looking at it and jpcap is forked all over the place - there is a project in Japan, one on sourceforge, as well as others - and it doesn't really run on Windows that well, or so it seems.

So it looks like we must go with the proxy solution for that part of our testing . . .

-Nathan

Harmeet Bedi wrote:
----- Original Message -----
From: "Nathan Carter" <[EMAIL PROTECTED]>

OK, so:

1) external tests = functional tests which mimic client behavior
according to RFC or a "recorded script"

2) internal tests = unit tests which largely follow James
class/component structure?

And I'm thinking that load/stress tests should share a lot of code with
1), so that even load/stress tests are less ad hoc

Thoughts?

Good point added parameters to ProtocolSimulator to specify simulation
iterations and number of parallel worker threads.



As a separate step, we will need to record scripts
of client server behavior between existing clients and existing IMAP
servers, and find a way to incorporate the peculiarities we find into
our testing infrastructure.

Started doing that a bit. Downloaded ipswitch IMAP server. How is your
tcpdump going. It would be useful. Alternatively I have been thinking of a
simple foward and record communication proxy.

Harmeet


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>





--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>

Reply via email to