[Gambas-user] Strings and Network input ...
nando
nando_f at ...951...
Wed May 9 19:20:48 CEST 2007
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
---------- Original Message -----------
From: Gareth Bult <gareth at ...1689...>
To: nando f <nando_f at ...951...>, mailing list for gambas users
<gambas-user at lists.sourceforge.net>
Sent: Wed, 9 May 2007 17:14:22 +0100 (BST)
Subject: Re: [Gambas-user] Strings and Network input ...
> Mmm,
>
> This however does increase the complexity of the application and the amount of
> work being done in Gambas.
> (which I'm guessing *will* slow it down, although to what extent I don't know)
>
> The main aim of the application is to provide a graphical IMAP sync tool ..
> which will typically load the machine in question right up to the hilt .. so
> performance will be an issue.
>
> Point is, assuming what you say is right, "LINE INPUT" is unsafe, unless there's
> an undocumented method of seeing whether the returned string was actually
> terminated by an and of line sequence .. you can never use LINE INPUT and be
> sure you actually have a line (!) .. Gareth.
>
> ----- Original Message -----
> From: "nando" <nando_f at ...951...>
> To: "mailing list for gambas users" <gambas-user at lists.sourceforge.net>
> Sent: Wednesday, May 9, 2007 4:54:19 PM (GMT) Europe/London
> Subject: Re: [Gambas-user] Strings and Network input ...
>
> I experienced a similar problem where I expected it to read up to a delimiter,
> but it turns out that LINE INPUT could read up to the end of the complete buffer
> because the whole line wasn't received yet, so it was a partial read...sometimes
> requiring two or even three reads. The data sent through the socket from another
> machine may take quite some time, so multiple read attempts will be required.
> I used _read for the socket and I appended what was received to a global receive
> string. Then I can find the delimiter at anytime independent of the read
> process. I added a 'time-out' timer to expect a delimiter within a certain
> period of time..so then the whole thing won't get hung-up because the imap
> server is too slow or went off-line(etc). This gives a huge amount of control.
>
> ---------- Original Message -----------
> From: Gareth Bult <gareth at ...1689...>
> To: Gambas User Mailing List <gambas-user at lists.sourceforge.net>
> Sent: Wed, 9 May 2007 14:22:55 +0100 (BST)
> Subject: [Gambas-user] Strings and Network input ...
>
> > Hi,
> >
> > I'm currently developing an IMAP4 client component and I seem to have run into a
> > problem.
> >
> > I'm using _Read on a Socket object when data comes in, then I'm doing;
> >
> > $socket.EndOfLine = "\r\n"
> > LINE INPUT #$socket,buffer
> > Process(buffer)
> >
> > Now I understand this to mean that Process() will only get called with
> > "complete" lines.
> > i.e. lines that were terminated by a CRLF.
> >
> > If I issue a SEARCH command against my IMAP server, I get a variable length
> > string, and for a large folder I'm expecting a string of length 41140 to come
> > through. However (!) Process is being called TWICE, the first time with a string
> > of length 41116 and the second of 24.
> >
> > So it "looks like" LINE INPUT is running out of buffer space and silently
> > splitting the string in two ... (????)
> >
> > I'd rather not have to code CRLF detection for READ .. is this a bug, something
> > fixable, or am I missing something ?
> >
> > tia
> > Gareth.
> >
> > --
> > Gareth Bult, Encryptec Limited
> > Tel: 0845 25 77033, FWD: 753977, Mob: 07891 389657
> > Email: gareth at ...1689...
> >
> > Statements made are at all times subject to Encryptec's Terms and Conditions of
> > Business, which are available upon request.
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Gambas-user mailing list
> > Gambas-user at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-user
> ------- End of Original Message -------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
> --
> Gareth Bult, Encryptec Limited
> Tel: 0845 25 77033, FWD: 753977, Mob: 07891 389657
> Email: gareth at ...1689...
>
> Statements made are at all times subject to Encryptec's Terms and Conditions of
> Business, which are available upon request.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
------- End of Original Message -------
More information about the User
mailing list