Chronological Thread 

< Chronological >      < Thread >

---

On Tuesday 30 November 2004 16:39, Vanegue julien wrote:
> Hi there,
>
> I'm experiencing severe data loss from a tcp socket when using
> ext_select() from the latest socketapi. I am afraid this is the
> sequel of a former bug that was reported 1 month ago on the list. Thomas
> provided me a first sctplib/socketapi patch but some problems still remain.
>
> TCP clients on (1), (2), (3) (... N ...) are sending requests to servers
> on (4), (5), (6), (... N ...) using a one-dgram-socket-multiple-streams
> sctp tunnel by sendmsg/recvmsg calls, and it works well when I try with
> telnet as a client and a web server at the other side for performing a
> 'simple GET' request.
>
> tcp clients ---> + ---- S C T P T U N N E L ---- + <--- tcp servers
>
>
> Nevertheless, in case of big traffic with multiple tunneled sockets,
> packet loss occurs on both way of the link (on the diagram, + represent
> SCTP proxies on both side of the test environment).
>
> I use 1 sctp stream per input TCP client socket. The
> stream multiplexing works well.

You use one SCTP association and tunnel each client <-> server association
via
a different stream?


> However it seems that ext_select() does
> not see some data (indeed delivered and received on the network,
> verified by sniffing), resulting in a partial web page (in case of www
> browser proxying).

Does the data reception just stop or are there data fragments of the
downloaded web page missing?


> Is there a more recent snapshot available that could resolve
> definitely this issue?

I prepare the lastest snapshot for you and send it via a separate e-mail. If
it does not work, send me your latest source code and information how to
reproduce the problem. Then, I can try to find out the source of the problem.


> I tried to use directly the sctplib on both sides of the link without
> socketapi, but in this way I dont know how to retreive the real
> data sender IP address in the DataArriveNotif() event. I looked
> deep inside the sctplib/socketapi source code, and the execution path
> that leads to the filling of 'pathindex' (which could help for getting
> the peer IP address of the TCP client/server that has sent the data,
> if using SCTP_pathStatus() ) seems useless in my case.

The data arrive notification is handled in
SCTPSocketMaster::dataArriveNotif(), it only gets the assoc ID from the
sctplib. Reading and obtaining the source address in handled in
SCTPSocket::internalReceive(). Here, sctp_receivefrom() is used to read the
data and get the path index (pathIndex variable) of the path the data has
been received via. Then, using sctp_getPathStatus() and
sctp_getAssocStatus(), the sender's address and port number can be obtained.


Best regards
--
=======================================================================
Dipl.-Inform. Thomas Dreibholz

University of Essen, Room ES210
Inst. for Experimental Mathematics Ellernstraße 29
Computer Networking Technology Group D-45326 Essen/Germany
-----------------------------------------------------------------------
E-Mail:
dreibh AT exp-math.uni-essen.de
Homepage: http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

Attachment: pgpEh9z1mhbiu.pgp
Description: PGP signature

---

• [SCTP-Discussion] Re: Latest socketapi data loss if using ext_select() on sctp-dgram socket (urgent), Thomas Dreibholz, 12/01/2004
  • [SCTP-Discussion] Re: Latest socketapi data loss if using ext_select() on sctp-dgram socket (urgent), Michael Tuexen, 12/01/2004

---

Archive powered by MHonArc 2.6.19+.