On Sun, 2009-03-01 at 14:01 -0500, Martin Peach wrote:
Martin Peach wrote:
Roman Haefeli wrote:
i don't know, how much control you have at c level over what is happening at tcp level. in order to solve the current issues at pd-level, information about either the current buffer size or amount of sent bytes (number of bytes removed from the buffer) would be required. i don't know how and if this is possible at all.
I don't think it's possible (but then I'm often wrong ;(). There might be an ioctl that will return the buffer size so you could know how much is safe to send at once.
Yes you see I was wrong. There is a getsockopt call that will return the buffer size. And a setsockopt that can also set the size on a per-socket basis. On WinXp I get 8192 for the default send buffer.
hm... knowing the actual buffer size isn't really helpful. what would be helpful is to know, what is the state of the buffer: is it empty or full? even the tiniest bit of information (empty or not empty) would solve all issues.
i really wonder, how other projects handle that. i mean, if several people download a big file from apache, then a disappearing client doesn't interfere with the other clients. i guess, in apache it is solved by using threads. when using threads, one single thread doesn't necessarily need to know about the buffer state, because it could be blocked without harm to the other apache children. so it can try to send as much data as possible. is using threads the _only_ solution to deal with that problem? i guess, it would overcomplicate the programming of [tcpserver], but you sure know better...
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de