Re: Do I want an ACK in my high-level protocol when using TCP?

On Dec 18, 6:22 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Dec 18, 2:30 am, JC <jason.cipri...@xxxxxxxxx> wrote:

I can't think of any other way to do it... how could I do this with
just one thread?

Nobody is saying to use just one thread. If you need to do work, do
it. Don't force a particular thread to do it. Let whatever thread
happens to be running do whatever work needs to be done.



queue requestqueue; // queue of requests from other threads

commthread {
  for (;;) {
    wait until requestqueue non-empty OR data received on socket (*)
    if requestqueue non-empty {
      dequeue and send request
    }
    if data received on socket {
      receive into some buffer (can this be partial receives?)
      if buffer has complete response in it {
        // ^^ this is just to handle partial receives...
        process response
      }
    }
  }

}

That doesn't seem much better... and I'm not sure how to implement
(*). Waiting on a socket with select() while waiting on a queue with a
cond var or something at the same time?

You could have one thread block in 'select' or 'poll' and when it
detects work that needs to be done, queue jobs to a thread pool. Other
threads could pull jobs from that pool and do them. You could also use
one of the many event libraries that uses high-efficiency internals
(kqueue on FreeBSD, epoll on Linux, and so on).

If it makes a difference only request send performance matters; also
the requests are likely to be very large amounts of data (10's or
100's of kB) while the responses are likely to be very small (10's or
100's of bytes). So if the performance issues you're talking about are
TCP overhead, is it the kind of overhead that large amounts of data
would make negligible?

It depends what you mean by "performance". Do you mean latency?
Throughput? CPU consumption? Or what? How many connections do you
expect to have at once? And what's going on during the processing of a
request? Disk access? Network I/O? Waiting for hardware or remote
events?

Latency is not important. Request throughput is important. Low CPU
consumption is somewhat important but not critical. I only expect to
have those 2 connections to B at once. They're established by
application A when application A starts. If at any point the
connection is lost, application A will hold back sending requests
indefinitely until it can re-establish the connection or it runs out
of memory.

In application A, during the processing of a request, there is some
other network I/O in the application. There should be none or very
little disk activity. There is no hardware access.

Basically, application A takes some events streaming in over the
network (low bandwidth) from a remote server, looks up a lot of
information in a database related to each event, does a bit of logic
and sends requests over the network to application B based on all that
information. In the mean time, application B processes the data and
sends results back. Application A then receives the results back
(while still building and sending requests), and possibly places
information in a second remote database based on the results.

So there are a few network connections
- single connection to server streaming data in slowly.
- multiple connections (< 10) to first database server
- multiple connections (< 3) to second database server.
- one or two connections to application B.

The reason I wanted to use a dedicated send and receive thread to B is
because it was really easy.

So... when you talk about using a thread pool, do you mean that rather
than having a single dedicated request thread, instead I have multiple
threads making requests at the same time? In that case, I have to
create a separate connection to application B for each thread
otherwise B has to have logic to piece split up requests back together
(since they could get mixed together if they're sent in multiple TCP
packets) -- that adds a lot of complexity to B. And also if I create
separate threads with separate connections, then doesn't that run into
the TCP optimization issues you mentioned earlier?

I appreciate what you're saying but I still really can't think of any
better way besides a dedicated send and receive thread. You mentioned
it was one of the worst architectures in terms of performance. What is
the major issue with it that makes it perform so poorly (given that I
care more about throughput than latency)? If I know that, at least I
can try to find a solution that doesn't have that issue.


Thanks,
Jason
.

Relevant Pages

  • Re: Socket Programming
    ... * Single threaded application that multiplexes concurrent connections ... Some requests may be served within millisecond time scale. ... On a single cpu system, ... do is keep some rolling counter of number of connections accepted in ...
    (comp.lang.lisp)
  • Re: IOCP Across Threads - Error 995
    ... The problem is that when a thread exits with outstanding overlapped ... send requests in progress all of those requests are cancelled - See: ... I have created an additional thread that initiates connections to the ... I placed a Sleepat the end of the outgoing connection ...
    (microsoft.public.win32.programmer.networks)
  • zombies with AMD64 and 32 bit userspace with 2.6
    ... the test is a simple forking proxy that receives connections from one ... machine (running apache benchmark) and forwards them to anothr machine ... to do a test with more then about 30,000 requests in it the box starts to ... the smaller tests leave no zombies at all and can be run multiple times ...
    (Linux-Kernel)
  • Re: Network Firewall/Routing Solution
    ... >> firewall combo boxes that linksys sells, and I really don't want to run ... >> not working properly at all with multiple network cards. ... >> like Unicode and header information for http requests, ... >> non-pasv connections. ...
    (comp.security.firewalls)
  • Re: Using generate statement in Verilog
    ... I get into trouble when I try to ... port connections. ...   generate ... Note that the 2005 version of the IEEE-1364 Verilog ...
    (comp.lang.verilog)