[Gambas-user] Strings and Network input ...

[timothy]

I agree with Daniel. I would just suggest that a version of
Daniel/Benoit's comments are added to the help for LINE INPUT as the
help does not highlight this problem.


Thanks

8-{)} Timothy Marshal-Nichols
<mailto: timothy.marshal-nichols at ...247...>

 

> -----Original Message-----
> From: gambas-user-bounces at lists.sourceforge.net [mailto:gambas-user-
> bounces at lists.sourceforge.net] On Behalf Of Daniel Campos
> Sent: Wednesday, 09 May 2007 09:15 PM
> To: mailing list for gambas users
> Cc: nando_f at ...951...
> Subject: Re: [Gambas-user] Strings and Network input ...
> 
> Hi:
> 
> I don't know why changing anything... when you read from a socket you
> don't know when the other part will send the complete message, so the
> programmer has to care about this, discard incomplete messages and so
> on, that's life: you're not reading data from your own safe hard disk,
> the communication may fail in any moment, and any programmer should
> care about that or things will become wrong in its program.
> 
> The programs which just block until they receive a complete message,
> use to just hang forever if something fails, like the old Netscape
> Navigator for Linux: without threading it waited for DNS query
> sometimes forever providing a distressing interface.
> 
> Anyway you can use the Peek() method in the _read event to read the
> data without extracting it from the socket buffer, that is, without
> creating any Gambas String buffer if you don't want to, until you find
> a Chr(0), Chr(13) or whatever using Instr() for example, It's not so
> difficult.
> 
> Daniel
> 
> 
> 2007/5/9, Benoit Minisini <gambas at ...1...>:
> > On mercredi 9 mai 2007, nando wrote:
> > > Actually, the complexity increase isn't really too much more.
> > >
> > > 1) have a public var for the receive buffer (string)
> > > 2) use _read for the socket to continuously append to that string
> > > 3) use INSTR to look for \n\r.  IF it finds it, remove the string
and
> use
> > > it. -Fernando
> > >
> > >
> >
> > Yes, LINE INPUT is only safe when you use file streams. When you
> > use "character" streams, i.e. sockets or process output, you cannot
read
> as
> > much data as you want.
> >
> > In that case, LINE INPUT takes the end of the buffer as an end of
line,
> so you
> > cannot know if you really read a full line, or just a part of it
because
> the
> > buffer is void - if the socket didn't receive the data yet, for
example.
> >
> > A solution could be having blocking input/output, but then your LINE
> INPUT may
> > wait for the data until a timeout occurs (for a socket) or forever
(for
> a
> > void pipe). And this can lead to other problems.
> >
> > So at the moment, I don't know how to make the situation better. If
> someone
> > has some idea about the semantic of LINE INPUT and other stream
> functions, he
> > is welcome!
> >
> > Regards,
> >
> > --
> > Benoit Minisini