Databases
StackOverflow2013
Postsdbo
POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
    primarykey
    data
    text
    <p>I'm trying to lower the send buffer size on my non-blocking TCP socket so that I can properly display an upload progress bar but I'm seeing some strange behavior.</p> <p>I am creating a non-blocking TCP socketed, setting SO_SNDBUF to 1024, verifying that is is set properly, then connecting (tried this before and after call to connect with no difference).</p> <p>The problem is, when my app actually comes around and calls send (sending about 2MB) rather than returning that around 1024 bytes were sent, the send call apparently accepts all the data and returns a sent value of 2 MB (exactly what I passed in). Everything operates properly (this is an HTTP PUT and i get a response, etc) but what I end up displaying in my progress bar is the upload sitting at 100% for about 30 seconds then the response coming in. </p> <p>I have verified that if I stop before getting the response the upload does not complete so it's not like it just uploaded really fast and then the server stalled... Any ideas? Does windows even look at this setting?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USOgapo
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSO_SNDBUF is the maximum size of your send buffer ... trying to send 2MB at once with 1 kB buffer sounds a bit strange to me. You should probably either increase your send buffer to more than 2 MB or make sends smaller than 1kb. I think you mistakenly believe that setting SO_SNDBUF will "cut" your 2 MB in 1 kB segments and send them one by one, you need to do it yourself.
      singulars
      1. POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
      1. USJ.N.
    2. COMy impression is that it's supposed to limit the amount of data that can be queued at any time though, right. Basically I just need an indicator for how much data has actually been transmitted (as opposed to queued). The size of the buffer isn't really relevant to me, I just wanted to pick something small enough that I should see some granularity. Is there a better way to do this? HTTP doesn't have any sort of built-in mid-upload ACK afaik.
      singulars
      1. POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
      1. USOgapo
    3. COYes it is that. If you can queue only 1kB, you can't send 2MB. Why it pretends it did send 2 MB is another problem. Keep in mind that whatever you do, TCP may very well combine or split your packets behind your back (see Nagle). You should split your sends by yourself, I guess that in your case something between 10 and 50 kB should do. To see the upload going on, use Wireshark or a proxy like Fiddler2.
      singulars
      1. POStrange behavior using SO_SNDBUF on non-blocking TCP socket under windows
      1. USJ.N.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload