Olivier,
That sounds like a good idea, there have been lots of bug fixes, etc.
since then and getting the new code into the hands of more users would be
great.
The extensive changes are limited to iomodel.diff, the rest of them are
pretty simple. Unfortunately, there was no good way to break up the
iomodel patch into smaller ones (once you start changing one thing there
is a large cascade).
The other thing that you might want to skip in rc9 is the warnings.diff
change to the Makefile which adds -Wall -Werror. This is good for
developers, because it forces us to do things a little bit more cleanly
and can catch bug-a-boos like incorrect printf formats, functions w/ no
returns etc. However, depending on the exact system the user compiles it
on, there could be warnings that prevent SIPp from compiling. I think a
good middle-ground position would be to apply the warning fixes, but not
the Makefile change in rc9, but put the Makefile change in SVN after rc9.
Charles
"Olivier Jacques" <[EMAIL PROTECTED]> wrote on 03/14/2007 06:29:54 PM:
> Charles,
>
> we are looking into those.
> What I will do is do an rc9 without those changes that are pretty
> extensive (rc8 is from December 06). That will give us a bit of time
> to stabilize.
>
> Thanks!
> Olivier.
> On 3/14/07, Charles P Wright <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> I've attached a new patch set with the following patches:
>
> - vgfix.diff
> Various valgrind fixes.
> - warnings.diff
> Allow the code to compile with -Wall -Werror on Linux.
> - doublelost.diff
> Allow loss percentages less than 1 and also a global command line
> option to specify that packets should be lost at a given
percentage.
> - usedrtds.diff
> Only include RTDs that are actually used in the CSV output.
> - micrortt.diff
> Use RTDs that are precise to the microsecond in -trace_rtt, and
> improve the consistency between trace_rtt and the averages.
> - iomodel.diff
> Completely reworked the network I/O subsystem so that all of the
code
> goes through a single read and single write function. This
ensures
> that no partial writes can get mixed, and eliminates TCP read
> deadlocks. The code is also cleaner as all of the information
> related to a given socket is stored in one structure.
> - clockupdate.diff
> Update the clock_tick more frequently so that we have a higher
timer
> and statistics resolution.
>
> The biggest thing here is the new I/O model (actually the biggest
> patch that we have submitted to date). I have basically reworked
> the entire read and write paths for network sockets, and
> encapsulated all of the information SIPp needs about the socket into
> a single structure (sipp_socket). The same primitive functions are
> used regardless of the socket type and there are fewer layers that
> must handle various error conditions (e.g. congestion). Aside from
> a general cleanup, this addresses two important problems:
> (1) We have observed that under TCP congestion SIPp was truncating
> packets and subsequent packets would be sent out before the partial
> message went through.
> (2) SIPp using TCP can not talk to another SIPp instance using TCP,
> because they would deadlock. The reason is that SIPp used to block
> until a whole message is read and both peers could have sent a
> partial message due to congestion. This results in both of the SIPp
> instances waiting to read, and never completing the partially sent
message.
>
> I have tested basic UDP (w/ and w/o multi sockets), TCP (w/ and w/o
> multi sockets), TLS (w/ and w/o multi sockets), 3PCC, and per-IP
> sockets. I have not been able to test compression (there are no
> public plugins I am aware of) and 3PCC extended (there are no
> publically available scenarios I could see).
>
> Aside from correcting the flaws that I mentioned and cleaning up the
> code, this should improve the extensibility of the code for two reason:
> (1) New information can easily be stuck in the socket structure.
> (2) There is an accurate mapping of calls to sockets (and an
> associated reference count)
> (3) There is less reliance on global variables for the network
> primitives. For example, transport and ipv6 are stored in the
> socket structures. This should (theoretically) make it easier to
> mix TCP and UDP or IPv4 and IPv6 in the future.
>
> Of course, if you have any questions about any of these patches,
> I'll be glad to answer them,
>
> Charles
>
> --
> Dr. Charles P. Wright
> Research Staff Member
> Network Server Systems Software
> IBM T.J. Watson Research Center
>
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sipp-users mailing list
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users
>
>
>
>
> --
> HP OpenCall Software
> http://www.hp.com/go/opencall/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
