Help for people with port 25 blocked please

Is there any way you could change the llEmail function call to be able to send it to a non standard port as some of us on Cox high speed internet have port 25 blocked and can't recieve the email on this port. Also try to look at xml-rpc with support for non port 80 support as this port is also blocked.

no-ip has some cool port 25 redirect stuff that is pretty cheap. You would instead have the MX for the domain you are emailing to point at one of their servers, and they redirect back to yours on a port of your choosing.

have you used thier services? they any good?


still just changeing the port shouldn't be too hard, and alot cheaper for me

If they're going to change it, I'd like to see them add in a port specifier, because if they go and change it, it will break all the things based on the standard that SMTP is, which uses port 25.

That way if you don't specify anything, it just uses port 25.

I'm not quite sure why you need them to change the SMTP port, since SMTP is outgoing you really don't have to check that port? Could you elaborate?

If i run a mail server, it has to listen on port 25 for incomming connections. If the isp block port 25, the second life server cannot connect to my server and deliver its email. So if i want to use llEmail to do anything interactive (something in SL sends an email, my custom smtp server then parses the email and responds to it) then i need to connect on some port other then 25.

incoming mail is normally on port 110 and outgoing on port 25.

another redirections service is www.dynu.com I have used dynu for around 3 years now and found it trouble free. They do have some free services and support Linux with some free client software.

Hope this helps

That's not exactly accurate, Garth. SMTP servers talk to each other on port 25. (25 is the standard SMTP port.)

When most people check their e-mail with an e-mail client, the client uses port 110 to communicate with the POP3 server. (110 is the standard POP3 port.)

But as a general rule, unless working around something like Hiro's problem, SMTP servers always talk to each other via... SMTP... which is port 25.

Hiro, I suggest you go ahead and look into one of the services like no-ip. Most likely, the sim/object server sends the outgoing e-mail to an internal SMTP server, which then attempts to connect to your SMTP server. Writing a custom SMTP relay, and coding all the support for dynamic port selection, is probably more hassle than LL wants to get into. I imagine this is the very reason they're using estalished standards, such as SMTP e-mail and XML-RPC, instead of rolling their own in/out-of-world communications protocols.

Grim is correct:

llEmail simply sends email, using Internet standard SMTP.

XML-RPC will be done via port 80: however, this shouldn't affect you, since you'll be making XML-RPC requests to our servers on port 80, which you will obviously have to be able to do (in order to web browse).

Arguably, your ISP should not be blocking ports without your permission. If they are doing so, I suggest using another one.

OK cool, haven't looked into how xml-rpc worked so its good that i'll be able to use it.

The problem with switching isp is there isn't alot of choice for broadband.

Hiro:

Fair enough. It's unfortunate that Comcast takes a dim view of how the Internet actually works.

I'm pretty spoiled; I have access to 3 seperate broadband providers in my area, which tends to make it easier to dodge this sort of semi-Internet connection.

Another solution would be to have llEmail() send to an account on a POP3 hosting service, and then using something like fetchmail to poll that account. That would work pretty well.

Mark, I know that with the XML-RPC standard, you can specify a port in the web address. For instance, if you need to use port 8080, when you specify the web address of the XML-RPC server to contact, you can use: "http://www.mydomain.com:8080/MyRpcServer" to "initialize" the client.

Will XML-RPC in SL have this same capability?

For that matter, is there any documentation available yet on how the new XML-RPC stuff is envisioned to work? What will the commands/syntax/capabilities/limitations be?

I've been waiting for something like XML-RPC (real-time persistant data storage) since last August or thereabouts, and I'm anxious to start working on designing some ideas for using it.

Is there any way some of us more ambitious types can assist in testing features that haven't been released yet? If so, I'd like to volunteer to give XML-RPC a test-drive.

Grim:

The XML-RPC implementation that will be released with 1.4 will be an XML-RPC server on our end that you can use an XML-RPC client to communicate with scripted in world objects. In world objects will not have access to an XML-RPC client, at least initially.

XML-RPC will be available on the Preview grid when it opens, and I certainly hope that people test it.

For this initial release, the support is very limited; there is a single RPC call (llRemoteData) that can send an integer and a string to a script that has registered itself with the RPC subsystem. The script can then generate a reply of an int and a string that gets returned by the the llRemoteData call to your XMl-RPC client.

While this is limited, I think you'll be able to do some pretty cool stuff with it, and what people do with this stuff is certianly going to influence what we add in the future.

All of this will be documented in the LSL Scripting guide, and I'm sure that the badgeometry folks will then immediately rewrite it so that it's useable.

This doesn't sound anything like what I was hoping for. To be honest, I don't think it will help with any of the things I've wanted to do at all. :/

I was hoping for an XML-RPC client, even a limited one, so that my in-world objects could communicate with my real-world server and get an immediate response, without the e-mail delays.

Oh well, wait and see, I guess.

BTW, what preview grid? This is the first I've heard of it.

The preview grid, and preview client, are usually announced at the following location...

http://secondlife.com/preview/

Note: the link currently shows the old Version 1.3 preview from awhile back.

Thanks, Hank. I'll keep an eye on it.

Assuming this means LSL can only serve RPC requests from the outside, and can NOT initiate a RPC call to the outside, this pretty much makes it impossible to use RPC for data storage/retrieval.

So, we're back to square one on that issue. What are we to do for persistent data storage?

I could be wrong, but wasn't the ability to write to a notecard given lower priority when it was determined that RPC would be implemented, and would provide an effective solution to persistent storage?

Grim:
Your objects _can_ communicate with your real world server with immediate response; your server just has to be the one initiating the connection, not your in-world objects.

Kex:
You can use this for persistant storage; it's admittedly not as clean, but it would still work, I think.

Frankly, there are significant risks to providing a useful XML-RPC client that we haven't yet solved (many of them involving using Second Life as a spectacular DoS attack mechanism). We do plan on providing this functionality, but it's going to be better for everybody if we do it right. Until then, this is new functionality which is interesting, and has much lower latency than the llEMail() interface. There are also potentially interesting things you could do with llEmail() and the XML-RPC interface, too.

My plans included:

1) persistent data storage, and retrieval of that data, using my web server/SQL database

2) moving complex and/or large logic blocks out-of-world so that I wouldn't have the 16k heap restrictions and suffer from the time-slicing issues that scripts have.

Actually, because of the size restrictions and time-slicing delays, I can't conceive (off the top of my head) of any "server" that I would write that wouldn't suffer from a 16k memory limit.

As a matter of fact, I actually tried writing a server (or 3) back in October. I got so frustrated with heap collisions and list/string bugs that I not only quit working on the servers, I quit logging into SL completely for about 6 months. :-/

Polling.

ie, write a program that does:

Hello SL, any data for me to save or retrieve? No? Ok.
Hello SL, any data for me to save or retrieve? No? Ok.
Hello SL, any data for me to save or retrieve? No? Ok.
Hello SL, any data for me to save or retrieve? No? Ok.
Hello SL, any data for me to save or retrieve? No? Ok.
Hello SL, any data for me to save or retrieve? No? Ok.
...loop forever...

=(

Mark, my problem is that I don't have a T-3 at home, nor does my ISP guarantee me 99% up-time. And, I live on the East Coast. I get some latency just from the fact that I live a few thousand miles away from SF.

My web server, on the other hand, is on multiple T-3's with guaranteed uptime, and is located in San Diego. But I can't install arbitrary software on it. If I could, the e-mail interface would probably work for me. I'd just write a custom SMTP server.

Grim:

You don't need the email interface. For example, if your server has Perl, something like this would work:

#! /usr/bin/perl -w

use strict;

use Frontier::Client;
use CGI qw(tandard);

print header,
start_html('A Simple RPC Controller'),
start_form,
"Enter channel: ", textfield('channel'),p,
"Enter StringValue: ", textfield('stringvalue'),p,
"Enter IntValue: ", textfield('intvalue'),p,
submit,
end_form,
hr;

if (param())
{
my $channel = param('channel');
my $string = param('stringvalue');
my $int = param('intvalue');
if (! defined $channel or ! defined $string or ! defined $int)
{
print "Dude, you need to fill in all fields!";
}

my $rpcserver = Frontier::Client->new(
'url' => "http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi"
);
my @arglist = (
{
Channel => $channel,
IntValue => $int,
StringValue => $string
}
);
my $result = $rpcserver->call('llRemoteData', @arglist);
print $result->{'value'}->{'StringValue'}, p;
print p;
}

Sorry about the formatting, but I hope that you get the idea. The above is a CGI that lets you enter the int and string val directly, makes the request, and returns the response to the browser.

This doesn't have to be a web app; the Channel is returned to the script at registration time, but it doesn't change as long as the script doesn't change, so you can return the channel id to yourself via any mechanism, and then embed it in your program.

Kex:

You're right, it's polling. OTOH, it's only polling for now.

So what will be the throttle on polling interval? Can I poll once per second? 10 times per second? What if I've got 20 different projects that need data storage. What if I sell an object that needs data storage to 200 people? Sounds like a reverse DDOS will be inherent to this system to me.

Also, it's too bad that anyone who thought they'd be able to get by with a simple web host with PHP (for example) will now be left out on this feature. You can't implement polling from most web hosting packages. Now you're going to need a host that gives you shell access to run a persistently running program to poll back to SL.

This really wouldn't matter to me if we just had some simple persistent per-prim storage solution.

Notecards, database, info field, or whatever. Just something to store about 4-8kB worth of data would solve a lot of problems.

But this is bass-ackwards. :-/ I don't want to send data TO the prim from outside (well, I do, but not on the majority of the projects I envision.) I want the prim to be able to SEND data to the web server, or to retrieve data from the web server, as needed.

And my web site is on a Windows Server, with IIS and ASP.NET, because I'm primarily a Microsoft developer. (Boo later.) But this means that I don't have shell access, and I can't run code on the server that isn't triggered by an http request.

And I agree with Kex on the polling problem. Repetitive polling of the RPC server is tantamount to a DoS attack against the LL servers. Especially if we have multiple objects that need to communicate with the RPC server.

Not to mention that if I can't do what I want/need through my web server, that means I have to use bandwidth that I'd rather have available for the SL client.

It would be possible to combine e-mail with RPC to accomplish all the things I want, but that means I'd be pounding (polling) on the LL RPC server, AND pounding on my mail server to minimize latency. :-/

Guys,

This is our first pass at this kind of functionality. I agree with the both of you that this isn't going to do exactly what you are looking for. However, it should let you do things that you currently can't do. We are going to have an XML-RPC client at some point, just not with the 1.4 release. I know that is disapointing (it's disapointing to me, at least).

I'd rather have you guys DDoS us by mistake than have someone DDoS you using our system because we wrote the XML-RPC client wrong.