Getting started 2

Dec 27, 2010 at 4:29 AM

Hi,

I am using version 58327 but cannot get a connection to the application...keeps coming up with "couldn't connect to host".

I've tried <appname>.cloudapp.net and <appname>.cloudapp.net:21 with no success on the ftp client.

For some reason it's not getting past first base.

Any suggestions?

 

Regards

Coordinator
Dec 27, 2010 at 3:58 PM

Hi SuperRoo

You need to make sure you have enabled connections on port 21 via the Windows Azure firewall settings. Have you enable this?

Richard.

Jan 7, 2011 at 4:50 AM

Hi Richard,

well I was using CueFtp, which does not give any command information, but when I switched to FileZilla I could see what was going on. It is connecting but timing out:

Status: Resolving address of ftpStar1vn.cloudapp.net

Status: Connecting to 65.52.189.79:21...

Status: Connection established, waiting for welcome message...

Response: 220 FTP to Windows Azure Blob Storage Bridge Ready

Command: USER Roger

Response: 331 User Roger logged in, needs password

Command: PASS ****

Error: Connection timed out

Error: Could not connect to server

I received an initial error message from the WindowsAzureMMc :

System.ServiceModel.CommunicationException: HTTP Status Code: ResourceNotFound - HTTP Error Message: The specified resource does not exist. Details: The requested storage account was not found.
   at Microsoft.Samples.WindowsAzureMmc.Powershell.Host.ServiceManagementPowershellWrapper.ExecuteCommand(Command command)
   at Microsoft.Samples.WindowsAzureMmc.Powershell.Host.ServiceManagementPowershellWrapper.RetrieveStorageService(String name)
   at Microsoft.Samples.WindowsAzureMmc.ServiceManagement.Features.Diagnostics.RootViewModel.<ShowRoleList>b__13()
   at MicrosoftManagementConsole.Infrastructure.ErrorHandlingService.HandleExceptions(Action action)

 

which seems to mean that the storage account info is incorrect:

I have an account called starvn so I assume:

 the account name is: star1vn
the account key is the guid
the baseURI is nothing
Mode is "Live"

Also, how do you debug this locally? I tried running it and since it is an output type of class library it requires another app to call it?

 

Regards

Roger

Coordinator
Jan 7, 2011 at 8:21 AM

Hi Roger,

I am glad that you have been able to get the project working and accepting incoming connections.

The error message you have seen does indicate there is a problem with the credentials given. In your message, you stated that:

 

the account name is: star1vn
the account key is the guid
the baseURI is nothing
Mode is "Live"

 

The only thing I can pick up on here is that the account key should not be a GUID. It's actually your Primary Access Key (eg. "ghg/mlTh3Hkv5zstydi0sAEfT1rD2eK/L8LHJYU+uUS123DS2ZB5FBwRjf72Q/sLO/zLIUIl9iKHbPT6tfAxB==")

Debugging remotely is a little tricky at this time. If you do not have success after changing your access key as described above, swap the storage mode to "Debug" for testing purposes. It may be there is a bug somewhere in the initialisation of the library.

Please continue to post your feedback.

I will hopefully have another version coming out that will include some much needed refactoring.

Thanks,

 

Richard.

Jan 7, 2011 at 9:58 PM

Hi Richard,

my mistake...I was using a key not a guid, so that is not the problem.

Also I had Mode set to Debug when I first loaded, so that is what the error was.

All I did was take version 58327, compile it and publish it...there are no diagnostics to tell me what is going on either.

Regarding the debug, I was wanting to debug locally to find out what the problem is.

 Regards

Roger

Coordinator
Jan 8, 2011 at 10:16 AM

Hi Roger

Let me look into this for you over the weekend. I believe there is a problem connecting/authenticating (as indicated by the error message) but that may be because the code is looking for a config setting in the wrong place. I'll need to crack open the source code to take a look.

With regards to diagnostics, I'll see what scope there is for me to start writing out information to a diagnostic storage account. I'd be grateful for any suggestions you may have regarding what it is you'd like to see output in the trace information.

Regards,

Richard.

Mar 16, 2011 at 11:11 AM
Edited Mar 16, 2011 at 11:11 AM

Same here, I'm using development, and giving an username like "metest", and it said it cannot connect to the server :(

Status: Connecting to 127.0.0.1:21...

Status: Connection established, waiting for welcome message...

Error: Could not connect to server

Coordinator
Mar 16, 2011 at 11:16 AM
valerianot wrote:

Same here, I'm using development, and giving an username like "metest", and it said it cannot connect to the server :(

Status: Connecting to 127.0.0.1:21...

Status: Connection established, waiting for welcome message...

Error: Could not connect to server


Hi Valerianot,

So your issue looks to be different to superroo's, in that you are experiencing a connection error to the FTP worker role itself and superroo was experiencing an issue with the blob storage.

Can you verify that you are connecting via an active mode FTP connection (rather than passive) and that there is an endpoint configured to port 21 in the role configuration?

Thanks,

Richard.

Mar 16, 2011 at 11:35 AM
Edited Mar 16, 2011 at 11:42 AM

Hi Richard,

Basically, I took the latest version of your code and ran it :)

I checked the .csfg file and it made sense as it is, since I'm trying development only at this moment.

I've put a breakpoint on "socket = m_socketListen.AcceptTcpClient();" and apparently it's never getting a connection. This line is call once and the execution cursor never moves or stop there again.

I've disabled firewalls and antivirus, just in case.

I'm using FileZilla with "Active" option enabled rather than "Default" or "Passive".

I've checked with TCPView that there is something at TCP21:

DFloadbalancer.exe 4492 TCP 127.0.0.1 21 0.0.0.0 0 LISTENING

 WaWorkerHost.exe 6232 TCP 0.0.0.0 21 0.0.0.0 0 LISTENING

 

And I can also see how FileZilla is trying to connect but is getting no response:

[System Process] 0 TCP 127.0.0.1 21 127.0.0.1 51711 TIME_WAIT

Any idea? I'm too much into sockets but I this looks like an Azure issue because the socket is not getting reached.

 

This is the debug log:

Microsoft.WindowsAzure.ServiceRuntime Information: 203 : Role entrypoint . CALLING   Run()

Information: FTPRole entry point calledControl: Server starting.Information: Server is alive.

Microsoft.WindowsAzure.ServiceRuntime Verbose: 500 : Role instance status check starting

Microsoft.WindowsAzure.ServiceRuntime Verbose: 502 : Role instance status check succeeded: Ready

The thread '<No Name>' (0x1f88) has exited with code 0 (0x0).

Information: Server is alive.

Microsoft.WindowsAzure.ServiceRuntime Verbose: 500 : Role instance status check starting

Microsoft.WindowsAzure.ServiceRuntime Verbose: 502 : Role instance status check succeeded: Ready

Information: Server is alive.I

The last 3 lines appears over a over again, what appears to be good :)

Thanks.

Coordinator
Mar 16, 2011 at 11:43 AM

Sure; the code does however need some modifications to get it working in your environment though, including the addition of an endpoint in your configuration... This is likely the reason that the socket isn't even getting a connection in the first place.

If you obtained the latest download version, then you will have missed some of the updates in the newset changeset (#58327) which includes the endpoint definition for you (see http://ftp2azure.codeplex.com/SourceControl/changeset/view/58327#1039072).

The project is far from being polished and ready for production yet but with everyone's help, we'll get there I'm sure. If you can suggest any improvements or you make any code changes you think are worth contributing then please let me know and I'll permit access to the source control system for you.

Thanks

Mar 16, 2011 at 11:51 AM

With latest version, I meant latest source code not release :D I got it from here: http://ftp2azure.codeplex.com/SourceControl/changeset/changes/58327

I've checked the .csdef and there is a definition for the endpoint.

Right now we need a FTP solution in azure, and we are considering options, if we go on with this I will help. I just have to make it work to show it in the next meeting haha, so if you get any idea about what could be the problem would be great, I'll also try in my personal computer after work, because after see the code it looks reasonably good.

Coordinator
Mar 16, 2011 at 11:56 AM

Thank you for the compliment ;)

If you're using Filezilla, again, please make sure that you are using an Active mode FTP connection. Can you confirm this is the case, as passive mode connections do not work.

I will need to be able to reproduce this error before I can see why you're getting it, so I'll try that tonight when I get home.

Thanks,

Richard.

Mar 16, 2011 at 12:10 PM

I confirm that I've double checked that Active mode is used :)

I'll try it as well from my personal computer and see what happen.

Mar 16, 2011 at 12:49 PM

I've fixed the connection thing :D

I create a very simple sockets project in C#, and worked. But when I put in on a cloud solution, I can connect but in the moment I send some data the connection closes.

I found an example of using sockets in Azure ( http://blogs.msdn.com/b/davidlem/archive/2009/12/12/remote-command-service-for-windows-azure.aspx ) and saw he is using a IPEndPoint retrieved straight from the Azure configuration, so when I implemented this in my test solution it worked, and when I implemented it in the FTP solution it also worked.

Basically, add this method in SocketHelpers.cs:

        public static TcpListener CreateTcpListener(IPEndPoint ep)
        {
            TcpListener listener = null;

            try
            {
                listener = new TcpListener(ep);
            }
            catch (SocketException)
            {
                listener = null;
            }

            return listener;
        }

And change the creation of the socket in FtpServer.ThreadRun() to:

m_socketListen = SocketHelpers.CreateTcpListener(RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["FTP"].IPEndpoint);

You will see that the port in the IPEndPoint is different of 21, I think because the internal port in the instance doesn't need to be the same that the one in the endpoint. Actually in the end point you can specify also a local port, that probably only makes sense in the real Azure (in development the instances are using the local machine ports, are not virtual machines). So basically, you bind your service to TCP 21, but the instance where the code is running could be using another port.

Now I can go on trying :)

 

 

 

 

 

 

Coordinator
Mar 17, 2011 at 6:30 PM

Hi Valerianot,

Great contribution, thanks. I'd already changed CreateTcpListener() in SocketHelper.cs in the local development version, but I'd actually forgotten to modify the m_SocketListen variable to pull it's value from the correct InstanceEndpoint. I'll do this now and update the main source code in the next day when I can get access to my development machine.

Nicely spotted, I'll credit you in the check-in ;)

If you're interested in helping out on the project please drop me an email.

Thanks

Rik

Coordinator
Mar 17, 2011 at 6:31 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Mar 18, 2011 at 11:22 AM

Yes please, add me as developer on the project.

I've been reading about the FTP protocol yesterday, and I'm impressed something as defective as FTP has done it this far haha. Probably I won't be able to make PASV mode work totally, because the Azure limitations, but I'll give it a try :)

Cheers.