Re: Socket Send

Brian C wrote:
David Schwartz wrote:

"Brian C" <brianc@xxxxxxxxxxxxxxxxxxx> wrote in message news:MUqSf.20849$nB6.4616@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Any ideas on how to get rid of that delay? The delay isn't predictable, but it happens roughly every 10-30 messages.



Are your sockets blocking or non-blocking?

Your read algorithm is not very good. You should *always* call 'read' for at least 4,096 bytes. If you get "too many", you can process them later *without* having to call read again, so that's a *win*. Do not try to read the header separately -- same reason.

DS


The sockets are blocking. I did do some reading and saw that I should be sending/reading in 4k increments, so I figured I'd start blocking the data on the server side, which would mean I'd have to be locking a mutex for a buffer and having a seperate thread running every say half a second to flush whatever data is in the buffer. I've done it before on a process that reblocks the quotes and sends them into the mainframe trading systems, and it works exceptionally well, but I'm not to keen on doing it again.

Ok, so basically, you're suggesting:
1) Set the socket to non-blocking.
2) Do the select(), see there is data.
3) Do a read for 4k. If 4k is not available, it'll exit out right away.

That should work. It'll take some finagling because right now I have 1 function that does the read() and 1 that does the write(), and every process I have that does sockets uses them. So, I'd like to keep it w/ 1 read() & 1 write(), but I dont want to change every call, but I'll look into that.

Would it be beneficial to also try to block it in 4k increments before doing the write() as well?

I'm just curious though...the typical time for both reads is .000004 seconds, which seems like a reasonable time in my opinion. It may be inefficient to do 2 reads, but, the response time seems good to me. I'm just curious as to why sometimes it would be that fast, then sometimes it would be .15 seconds? And it's not because I'm doing multiple read()'s. I logged each return code of the read(), and I saw it took 1 time about 10-15 read()'s to read in the entire message (was getting small chunks each time), and it still completed in .000002 seconds.

Thanks for your time and reply!

Let me clarify.

I'm just curious as to what benefits reading a 4k block does? Is this something internal to the TCP/IP stack or?

Thanks again.
.

Relevant Pages

  • Re: Question on select() and sockets
    ... Making the sockets non-blocking guarantees control over when you block ... Although I was writing about pipes in my recent reply ... can still end up blocking, even if you only call reador write ...
    (comp.unix.programmer)
  • Re: blocking non blocking
    ... Ok now i am very confused...here is why i think non blocking is less ... non blocking sockets typically involve some busy waiting and ... somehow a server with 50K threads, ... or overlapped I/O servicing 50K clients. ...
    (microsoft.public.win32.programmer.networks)
  • Re: blocking non blocking
    ... not connected to incoming data on the same thread, async sockets have to be ... somehow a server with 50K threads, ... or overlapped I/O servicing 50K clients. ... read and learnt about blocking and non blocking, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Close a blocked socket
    ... ..NET, that non-blocking model is easier and should scale better, you decided ... by dedicating a thread or two to the socket i/o and using blocking ... using blocking sockets, then good for you. ... connection to the Internet on the server side. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Close a blocked socket
    ... which I believe blocking is fine, ... But if you are not using IOCP, then as you approach tens of thousands of connections, .NET Sockets will outperform a straight Winsock implementation. ... The exception that thread is complaining about is completely harmless, and is no different from any other informational exceptions that occur in .NET. ...
    (microsoft.public.dotnet.languages.csharp)