Grant Edwards escreveu:
> On 2006-06-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >>> Well, actually I´m using a very simple protocol wich sends
> >>> only strings ended by newline. I need to send 3 chunks of
> >>> information and a newline after them. On the reader side I
> >>> make 3 re
Steve Holden wrote:
> Nope, I wouldn't look any harder. You and I both know you won't find
> them. "The client" in this case was the client's transport layer, not
> the client application - I should have said "sender", since I referred
> to the system at the other end as the "receiver".
you kn
Donn Cave wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Holden <[EMAIL PROTECTED]> wrote:
>
>
>>The PSH flag indicates that the data stream must be flushed right
>>through to the other end. This is essential for interactive protocols
>>such as FTP: without it the server has no way to know t
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
> The PSH flag indicates that the data stream must be flushed right
> through to the other end. This is essential for interactive protocols
> such as FTP: without it the server has no way to know that the client
> has sent
In article <[EMAIL PROTECTED]>, Steve Holden wrote:
>> I don't think that's right. You are confusing the PSH flag (which is
>> basically unused in Unix networking I think) and the URG flag (which
>> is extremely rarely used, but is indeed used by FTP to get abort
>> requests to 'jump the queue' as
Jon Ribbens wrote:
> In article <[EMAIL PROTECTED]>, Steve Holden wrote:
>
>>Of course, if the client forces the TCP PSH flag true then the receiver
>>is guaranteed to debuffer the stream up to that point - this is how FTP
>>clients work, for example.
>
>
> I don't think that's right. You are
In article <[EMAIL PROTECTED]>, Steve Holden wrote:
> Of course, if the client forces the TCP PSH flag true then the receiver
> is guaranteed to debuffer the stream up to that point - this is how FTP
> clients work, for example.
I don't think that's right. You are confusing the PSH flag (which i
On 2006-06-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> Well, actually I´m using a very simple protocol wich sends
>>> only strings ended by newline. I need to send 3 chunks of
>>> information and a newline after them. On the reader side I
>>> make 3 readline(), this way I wouldn´t have to
[EMAIL PROTECTED] wrote:
> Yes, as I expected, its the buffers. In my opinion the problem is that
> the socket module doesn't provide a way of reading all its internal buffer.
umm. that's what recv() does, of course, of you pass in a large enough
buffersize.
for your use case, I suggest lookin
[EMAIL PROTECTED] wrote:
> Grant Edwards escreveu:
>
>
>>On 2006-06-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Well, actually I´m using a very simple protocol wich sends only
>>>strings ended by newline. I need to send 3 chunks of information and a
>>>newline after them. On the rea
Grant Edwards escreveu:
> On 2006-06-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Well, actually I´m using a very simple protocol wich sends only
> > strings ended by newline. I need to send 3 chunks of information and a
> > newline after them. On the reader side I make 3 readline(), th
On 2006-06-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Well, actually I´m using a very simple protocol wich sends only
> strings ended by newline. I need to send 3 chunks of information and a
> newline after them. On the reader side I make 3 readline(), this way I
> wouldn´t have to care ab
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I'm building a multithreaded application and I encountered a tiny and
> > annoying problem. I use a select to wait for data to be read from a
> > socket, after some reads, the select simply blocks and stays that way
> > until I close t
[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm building a multithreaded application and I encountered a tiny and
> annoying problem. I use a select to wait for data to be read from a
> socket, after some reads, the select simply blocks and stays that way
> until I close the connection on the other side of
Hi,
I'm building a multithreaded application and I encountered a tiny and
annoying problem. I use a select to wait for data to be read from a
socket, after some reads, the select simply blocks and stays that way
until I close the connection on the other side of the socket. When the
socket is close
15 matches
Mail list logo
