FTP not Returning (Python on Series 60 Nokia)

[mbukhin]

I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway. When I run
this in interactive bluetooth mode the storbinary command just hangs
(though the file ends up on the server). i've tried a bunch of
different things, counters, comparisons, everything. there's a signal
library in python but i don't think it's supported in mobile devices.

any suggestions?

thanks!

[Fredrik Lundh]

mb*****@gmail.com wrote:

I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway.

assuming that the connection works properly, the only way to get stuck
in the while loop is if the size of your file is infinitely huge.

so it's probably a connection issue; I suggest adding print statements
around the conn.send and conn.close calls, to make it easier to see
where you get stuck.

setting the debug level (e.g. ftp.set_debuglevel(2)) might also provide
some additional clues.

</F>

[mbukhin]

Thanks for the 'debug mode' tip. My file is only 24k (a photo) and the
whole thing makes it to the FTP server. It's just the command never
returns so my program cannot continue execution. When I do turn
debugging on, the last command I see is:

*resp* '150 Connection accepted'

Could it be my FTP server? I'm using a windows install of FileZilla.
I did have to make one patch to the ftplib. There is a documented
problem where routers mangle
return text:

227 Entering Passive Mode (192,168,0,3,13,248)

into something like

227 Entring Passive Mode (192,168,0,3,13,248

Pulling off the trailing paren (see:
http://filezilla.sourceforge.net/for...4948c2c84153b).
I edited the parse227 call to not look for the trailing paren.

Anywhere else i can look? I'm running my program line by line in the
bluetooth console and it hangs on the storbinary. When I run the
program directly on the phone as a single exe the same thing happens.

thanks

(Code & output)

Sample Code:

from appuifw import *
from graphics import *
from ftplib import FTP
import camera
import e32
import time
import httplib, urllib
from key_codes import *


picselection = 'e:\\picture.jpg'
ftp = FTP('xx.xx.xxx.xxx') # connect to host
ftp.set_debuglevel(2)
ftp.set_pasv('true')
ftp.login('mike','xxxxx')
F=open(picselection,'rb')
filename = time.strftime("%Y-%m-%d-%H-%M-%S.jpg",time.localtime())
e32.ao_yield()
ftp.storbinary('STOR ' + filename,F,1024) # store the image
e32.ao_yield()
ftp.quit()
F.close()

Debug output:

*cmd* 'USER mike'*put* 'USER mike\r\n'
*get* '331 Password required for mike\r\n'
*resp* '331 Password required for mike'
*cmd* 'PASS *******'
*put* 'PASS *******\r\n'
*get* '230 Logged on\r\n'
*resp* '230 Logged on''230 Logged on'

F=open(picselection,'rb')
filename = time.strftime("%Y-%m-%d-%H-%M-%S.jpg",time.localtime())
e32.ao_yield()
ftp.storbinary('STOR ' + filename,F,1024) # store the image

*cmd* 'TYPE I'
*put* 'TYPE I\r\n'
*get* '200 Type set to I\r\n'
*resp* '200 Type set to I'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entring Passive Mode (69,86,224,242,13,248\r\n'
*resp* '227 Entring Passive Mode (69,86,224,242,13,248'
*cmd* 'STOR 2006-03-29-02-59-13.jpg'
*put* 'STOR 2006-03-29-02-59-13.jpg\r\n'
*get* '150 Connection accepted\r\n'
*resp* '150 Connection accepted'

[Serge Orlov]

mb*****@gmail.com wrote:

I'm using the ftp library (layer on top of sockets) to transfer files
from a series 60 to an ftp site. everything works fine, the whole
file gets uploaded but the command never returns! so
i call:

ftp.storbinary('STOR ' + filename,F,1024) # store the image

which does this:

def storbinary(self, cmd, fp, blocksize=8192):
'''Store a file in binary mode.'''
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.send(buf)
conn.close()
return self.voidresp()

and the 'while 1' never stops. That's my guess anyway. When I run
this in interactive bluetooth mode the storbinary command just hangs
(though the file ends up on the server). i've tried a bunch of
different things, counters, comparisons, everything. there's a signal
library in python but i don't think it's supported in mobile devices.

any suggestions?

Assuming conn is a socket .send() method is not guaranteed to send all
the data. Use .sendall() method. Are you sure the *whole* file is
uploaded?

Serge.

[mbukhin]

Thanks, but that didn't help either. Since storbinary is being called
from the main script, I can't see where else it could be getting hung
up. Are there any other debugging techniques I could explore?

I'm sending a 24k image and it is viewable on the destination server,
so it's making it over. I can watch the FTP console and see that
transfer hits 24k and then the rate change to 0.0 Kb/s.

I have set up a timeout of 5 seconds on the FTP server at which point I
get a '426 connection aborted' on the python side. So somehow the
sides don't think they have completed the transfer? I could live with
this solution except i'd need a way to ignore the timeout error in
python and continue execution.

I just tried this code with a different file, System.ini, and I have
the same problem.

[Serge Orlov]

mb*****@gmail.com wrote:

Thanks, but that didn't help either. Since storbinary is being called
from the main script, I can't see where else it could be getting hung
up. Are there any other debugging techniques I could explore?

I'm sending a 24k image and it is viewable on the destination server,
so it's making it over. I can watch the FTP console and see that
transfer hits 24k and then the rate change to 0.0 Kb/s.

I have set up a timeout of 5 seconds on the FTP server at which point I
get a '426 connection aborted' on the python side. So somehow the
sides don't think they have completed the transfer? I could live with
this solution except i'd need a way to ignore the timeout error in
python and continue execution.

I just tried this code with a different file, System.ini, and I have
the same problem.

It looks like server/client incompatibility or a server bug. Maybe
you'll get some clues here:
http://fetchsoftworks.com/ubb/Forum2/HTML/002542.html
I suggest to try another ftp server.

Serge.

[mbukhin]

Right. You know I took your suggestion for more print statements and
found the offending line.

[SNIP]
print "close start"
conn.close()
print "close end"
#return self.voidresp()
print "end of everything"

self.voidresp() was hanging! Do I need it? The file seems to run
without it. I also found this:

http://www.techietwo.com/detail-6362036.html

[Serge Orlov]

mb*****@gmail.com wrote:

Right. You know I took your suggestion for more print statements and
found the offending line.

[SNIP]
print "close start"
conn.close()
print "close end"
#return self.voidresp()
print "end of everything"

self.voidresp() was hanging! Do I need it?

I don't keep the whole description of ftp protocol in my memory :)
You'd better read the RFC. But I suspect a server is supposed to send
some kind of confirmation that the file was successfully written on a
disk and a client is supposed to wait for such confirmation.

Serge.

[mbukhin]

Got it. Thanks for your help. :)