On Mon, 2009-03-02 at 18:51 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Sun, 2009-03-01 at 22:53 -0500, Martin Peach wrote:
So I made [tcpserver] send the messages one byte at a time. This latest version should not block, since it adds only one element to the buffer for each select call that says the buffer is still writeable.
can you tell me something about how to use it correctly? i just compiled the newest version and still could prevent it from blocking pd. before the blocking happens, i do _not_ get any message from the new outlet from [tcpserver], such as 'sent 0'. so what happens is still, that i send messages to it until it blocks. is it different on windows? do you mind sending me a windows binary, if it is? is there anything i can do in terms of testing on linux?
Sorry, there was a bug in it so it was staying in the send loop even though it couldn't send. I fixed it in the latest svn.
great news with great results! it works for me as well. no blocking anymore and a feedback of what could be sent: that is what i needed. thanks for your work.
When I use it, if I set the buffer size to 10 I can send 4 messages of 3 bytes after unpluggng the cable, but the last 'sent' says that only 2 bytes were transmitted. Subsequent attempts give 0. After a few seconds I also get a message saying the connection was terminated. It should work identically on linux.
same behaviour here as well with server on linux and client on OS X. the only difference: the connection is not automatically terminated (or probably i have to wait longer then 10min). windows seems to be more keen to close 'unused' connections. just for the record: actually i wanted to test only on one computer running ubuntu with windows in a virtual box, but it didn't work, because whenever i shut down the network device in virtualbox, the connection was terminated. so i had to use physically two computers.
i have some questions about the usage of [tcpserver]:
when sending lists of floats to it, tracking of what is sent and what not is not very trivial to do, since you have to count the elements of each message 'going out', so that you can compare it with the status output of [tcpserver]. in order to resend omitted parts, you also need to store a copy of the last sent list. now, since i want to buffer the outgoing messages anyway, buffering them as lists is unpractical anyway and i much rather would buffer them in an array. programming-wise, it would be much easier to send byte-by-byte, a.k.a sending a 'client 1 BYTE' for every BYTE separately. is that a stupid thing to do? would it cause a lot of overhead in terms of cpu cycles, when trasferring big amounts of data this way?
how do i know, when the [tcpserver] socket is ready to transmit another byte? do i have to nag it every ms with a message? if i go the BYTE-AT-A-TIME route, the interval would even need to be slower, if higher troughput should be achieved. is there any strategy to avoid too much overhead?
thanks roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de