57203fb8   
   From: spam@reppisch.de   
      
   hi, thanks for replying,   
      
   >   
   >>I experience strange lock-ups on older systems when submitting more than   
   >>64k in one call.   
   >   
   >   
   > The problem is likely elsewhere. Perhaps you mishandle returns values   
   > less than the amount you passed.   
      
   The same code is not showing the behavior on newer OS's. The one i   
   mentioned was SCO sys v.   
   Hopefully we have it out of the field now ;-)   
   The return value of send is the number of bytes sent. If -1 is returned   
     i query the last error on the sock via getsockopt(m_socket,   
   SOL_SOCKET, SO_ERROR...   
   "Wouldblock" is considered harmless, all other fatal.   
   What's the standard way to get the socket error (multi threaded env.   
   errno???)   
      
   >   
   >   
   >>2) strange problem:  select() doesn't wake up   
   >>   
   > This is likely a bug in your code somewhere. Perhaps the socket is not   
   > really in the write set?   
   >   
   The logs say it's in the fdset. Is it possible that some psh/ack packets   
   got lost? I'm no longer sure if i reproduced this on a crossed cable,   
   but I'm definitely sure i saw it on a "questionable" connection. I   
   noticed that even my ssh-session to the client was sometimes frozen.   
   which lead me to the idea to use a direct cable.   
   >   
   > You cannot use a socket in blocking and non-blocking mode at the same   
   > time.   
   yeah, that was clear ;-)   
     You can, however, use a socket from different threads providing   
   > you carefully synchronize the closing of the socket.   
   - so it's legal to have a blocking send in thread A and a blocking recv   
   in thread b.   
   - or do a select on write in thread a and on read in thread b.   
      
   or somewhat silly:   
   Do a select on same socket in thread a and b? which thread will be woken   
   in this case?   
      
   >   
   > It's perfectly fine. A common approach is to have sending threads and   
   > receiving threads. Trying to send from more than one thread on the   
   > same stream socket won't work without synchronization.   
   that's clear.   
   My approach is basically a select based server. Literature say's it   
   performs better than the threaded model, but unfortunately it's not   
   really fast.   
      
   In my case connections are long lived. Each connection consists of a   
   socket and two ring buffers + some synchronization stuff.   
      
   A observer thread is assembling fd-sets for read and write based on   
   ring buffer capacity. eg. don't put in fdset for recv when buffer is   
   full / don't don't put in fdset for write when send-buffer empty.   
   The observer thread is also observing a wakeup-socket for special purposes.   
   Then the observer thread sleeps on select with the fd-sets.   
   When it awakes, it's testing the sockets (fd_isset) i put in before and   
   does a tcp-send  and/or receive. The amount of data actually transfered   
   is committed to the ring-buffers. (i handle eagain/wouldbloc/nobuf) In   
   case of a tcp-read, a (non-tcp) message is sent to a receiver thread   
   that tries to de-queue a complete message from the ring buffer.   
   The dequeued Message is being processed and an answer message is   
   inserted into the send-ring buffer. Ring buffers are concurrency   
   protected by mutexes (maybe a performance problem. I'll think of   
   something tread safe and also lock free). Then i send data to the   
   wakeup-socket to interrupt a possible select sleep. the observer will   
   recalculate the fd_sets and send out the data in the next turn.   
      
   Any ideas to improve design? (Code has to be widely portable, so i'd   
   like to avoid epoll,kqueue,WsaAsyncSelect,completion ports and whatsoever)   
      
      
   >   
   >   
   > There is no such thing guaranteed. It's really not clear what   
   > "transfer capacity" means.   
   >   
   Ok, let me explain:   
   Your machine has a 100M bit NIC. You have two connected sockets.   
   You are sending on the two sockets in the same order.   
   First on a then on b instead of round-robin. We assume the receivers   
   would be able to soak up any amount of data in almost no time.   
   Is there a guarantee, that sock a sends as much bytes / second as sock   
   b. (In total they should use the NIC by 100% slit equally to a and b).   
      
      
   Regards,   
      
      Michael   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)