"Peter Higginson" <[EMAIL PROTECTED]> wrote on
04/25/2007 03:35:06 AM:
> >> One important thing to consider here is that we did not take care so
far
> >> of other protocols/transports than UDP (we think our design will
allow
> >> an easy integration of the others, but we did not 'port' the TCP and
TLS
> >> implementations over just yet). So a combination of our efforts will
> >> hopefully be very beneficial.
> >OK. I look forward to seeing your patch. One of the most
> important things that we did was to get all of the data for a single
> socket in a structure, >and create "choke point" functions for
> sending and receiving, which is especially important for TCP and TLS
> (which both need to deal with congestion, >partial messages, and
> multiple messages).
>
> Multiple IP addresses or ports with TCP is quite complex and you
> definitely need a structure/class to represent each open TCP call.
> Correct SIP protocol requires that responses use the same call as
> the corresponding request (if still open) but for requests you have
> to find or open a call to the address/port given in the last
> contact. (Simple calls are fine ? it is things like OPTIONS and re-
> INVITE by the called party that get messy.) That means remembering
> which TCP call a request arrived on and on sending requests scanning
> all the TCP calls in use to find if there is one already open that
> you can use or opening one.
One relatively large data structure improvement in there is that there is
a correct mapping of calls to sockets and vice versa. I did this by
always setting the call->call_socket to the actually used socket, throwing
in some reference counting and a multimap from sockets to calls. The
network code that I have does not attempt to do the socket matching, but
it would not be very difficult to extend it to do so using a map that maps
a (protocol, ip, port) tuple to a struct sipp_socket *.
> I also found TCP open taking up to 30
> seconds (usually due to socket reuse timeouts) so you cannot just
> freeze SIPP till a call opens, you have to keep state and poll.
I did not handle the blocking connect, or the blocking close case (the
latter becomes important if the socket is congested). If you have code
for non-blocking connect or close, I think that would be an important
feature to add.
> The multiple IP address code we have for UDP was taken from another
> project so I was never able to share it. (It is very messy anyway so
> you probably would not want it.) However I had to re-write the
> socket management to get TCP to work so there is no problem sharing
> that part and the changes to the SIPP files if that would help. (It
> does not include TLS though.)
I don't think that it could hurt. :)
--
Dr. Charles P. Wright
Research Staff Member
Network Server Systems Software
IBM T.J. Watson Research Center
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
