[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