tcp client using sockets

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

tcp client using sockets

kyle treleaven
I'm building a tcp client using the sockets api in lwip.  Am running
on xilinx port to the ppc of virtex fpga.  I base my client on the
echo server example, and I've posted here before about the same thing.
 I changed the code incrementally, very slowly, testing the
performance at each phase.  Basically, the client broke at the very
last step.  Up until that point I had been testing the client against
a very simple echo server.  I'd send it an initial byte representing
the number of times I wanted it to relay a phrase back and forth with
the client, and then I would receive, reply, receive, reply and so
on... ie. write(), read(), write(), read(), write(), read().... in an
arbitrarily long sequence.

The client breaks when i no longer do things in that exact order:
write(), read(), write(), read()...  That is to say I may still
receive the data, but only after a number of retransmit pushes from
the server, and with a delay of 10-20 seconds, which is clearly
unacceptable.  It's as though some interrupt or polling loop isn't
firing correctly, but all of the OS and lwip setup code remains
exactly as it was in the server example.  Has anybody else encountered
this?

Kyle


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp client using sockets

Sathya Thammanur
Hi Kyle,
There should not be any requirements on the sequence of read's and write's to be ordered. However, as far as I know, the socket calls for read and write are blocking. I dont think lwip supports non-blocking sockets unless someone can correct me on this. Can this be a reason for the behaviour that you are seeing?

Sathya


On 4/15/06, kyle treleaven <[hidden email]> wrote:
I'm building a tcp client using the sockets api in lwip.  Am running
on xilinx port to the ppc of virtex fpga.  I base my client on the
echo server example, and I've posted here before about the same thing.
I changed the code incrementally, very slowly, testing the
performance at each phase.  Basically, the client broke at the very
last step.  Up until that point I had been testing the client against
a very simple echo server.  I'd send it an initial byte representing
the number of times I wanted it to relay a phrase back and forth with
the client, and then I would receive, reply, receive, reply and so
on... ie. write(), read(), write(), read(), write(), read().... in an
arbitrarily long sequence.

The client breaks when i no longer do things in that exact order:
write(), read(), write(), read()...  That is to say I may still
receive the data, but only after a number of retransmit pushes from
the server, and with a delay of 10-20 seconds, which is clearly
unacceptable.  It's as though some interrupt or polling loop isn't
firing correctly, but all of the OS and lwip setup code remains
exactly as it was in the server example.  Has anybody else encountered
this?

Kyle


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp client using sockets

kyle treleaven
I don't believe the blocking nature should be a problem in this case.
The socket is used in one thread only, which read()s for incoming
data, processes, may or may not generate a response, write()s, and
then repeats.

It's in the same form as the example: ie.

open socket;

while( read() > 0 )
{
  process; <-- maybe write()
}

close socket;

>From Ethereal captures it seems more likely that the outgoing data is
copied into a buffer and then forgotten until any kind of new incoming
traffic.  That is, the write() command always returns immediately,
even though nothing actually goes out.  So the loop blocks again in
the while-loop's conditional.  Then, when new traffic or tcp
retransmit commands come in, the previous data is finally actually
shoved out.

Does that make any sense?

Kyle


On 4/17/06, Sathya Thammanur <[hidden email]> wrote:

> Hi Kyle,
> There should not be any requirements on the sequence of read's and write's
> to be ordered. However, as far as I know, the socket calls for read and
> write are blocking. I dont think lwip supports non-blocking sockets unless
> someone can correct me on this. Can this be a reason for the behaviour that
> you are seeing?
>
> Sathya
>
>
>
> On 4/15/06, kyle treleaven <[hidden email]> wrote:
> >
> I'm building a tcp client using the sockets api in lwip.  Am running
> on xilinx port to the ppc of virtex fpga.  I base my client on the
> echo server example, and I've posted here before about the same thing.
> I changed the code incrementally, very slowly, testing the
> performance at each phase.  Basically, the client broke at the very
> last step.  Up until that point I had been testing the client against
> a very simple echo server.  I'd send it an initial byte representing
> the number of times I wanted it to relay a phrase back and forth with
> the client, and then I would receive, reply, receive, reply and so
> on... ie. write(), read(), write(), read(), write(), read().... in an
> arbitrarily long sequence.
>
> The client breaks when i no longer do things in that exact order:
> write(), read(), write(), read()...  That is to say I may still
> receive the data, but only after a number of retransmit pushes from
> the server, and with a delay of 10-20 seconds, which is clearly
> unacceptable.  It's as though some interrupt or polling loop isn't
> firing correctly, but all of the OS and lwip setup code remains
> exactly as it was in the server example.  Has anybody else encountered
> this?
>
> Kyle
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users