www.webdeveloper.com
Results 1 to 10 of 10

Thread: Communicating on ports other than 80

  1. #1
    Join Date
    May 2010
    Posts
    168

    Communicating on ports other than 80

    I have a remote client that has a ridiculous latency over port 80, and we're looking to increase response time. Due to other factors, they do have a decent response time when sending email.

    It's a long shot, but I was wondering. Is there any way to open a port other than 80 via browser using javascript?

  2. #2
    Join Date
    Jan 2005
    Posts
    369
    I'm not quite clear on what you are trying to do (it sounds like it may well be a bad idea in the long run) but you can use any Protocol on any port if you really want to, and if you have enough control over any firewalls between the client and server. Many proxies / firewalls will reject unusual traffic on a standard port, but all you need to do is specify a port number in your url:
    Code:
    http://www.example.com:25/index.html
    is totally valid, assuming that the server is configured correctly.

  3. #3
    Join Date
    May 2010
    Posts
    168
    Hi Om,

    Sorry about not being clear on this, I'm kind of getting my head around the problem myself. We're still in the design phase of this, so now's the time to get my head around it.

    We can request proxy/firewall setup if necessary, we're not trying to be sneaky about anything, it's just that anything that leaves on http:80 goes over satellite (and it's like being on an old 1400 baud modem if you're a cruise ship out at sea), while their email has more redundancy built in (it can relay from ship to ship to port, and can basically leave other ways than just going to the satellite).

    I thought that when using your code snippet, it would be a connection leaving from port 80 and going to port 25. If that's the case, then that's not what I want.

    I want to be able to simulate a message as though it were an email being sent from an MUA. That means leaving from what I'm assuming is the appropriate send port, and connecting to theirs, thus utilizing their existing architecture, from a webpage. This might be as easy as specifying the protocol, or simply specifying the receive port on the host, but it might be as complex as needing a library or something like java. I'm unsure.

  4. #4
    Join Date
    Jan 2005
    Posts
    369
    I think we need to make another step back - what are you trying to send?
    I'm not quite clear on which end is the client, and how much of the path you have control over?

    Clearly you know at least a little about your bottle-necks, but the problem is that there are generally four factors affecting the speed of a network: speed, bandwidth, reliability and latency. Different applications will be more sensitive to one or the other, so we firstly need to understand what the most important thing is, and how the factors differ between satellite and ship-to-shore transmission routes.

    The only inherent difference (other than one is push and the other a pull) between SMTP and HTTP transport is that HTTP must always be a direct connection, (unless proxies are involved) whereas SMTP is less reliable as it relies on each hop getting it nearer to its destination which is only theoretically true.

    Are you actually

  5. #5
    Join Date
    May 2010
    Posts
    168
    I think we need to make another step back - what are you trying to send?
    We're working with a scheduler, basically updating port times, notifying where we're going to be and when we're going to be there. Because of the problem we're having with the latency, which basically makes takes about 6 seconds to make a simple ajax request (< 1k up, about 1k down). So we're looking at sending some kind of update over the email line, maybe json, maybe csv, depending on what we can rig on the other side and have a script check for messages, parse them, do something with it, then reply.

    I'm not quite clear on which end is the client, and how much of the path you have control over?
    Clients are run on the ship. We're basically creating a web interface to the scheduler. We can configure, or ask for a configuration change, of any data at our end points (anything before the communication leaves the ship, and anything after the message hits our domain). There is some hardware on ship between our box and the cloud, and that routes messages over the appropriate channels.

    Clearly you know at least a little about your bottle-necks, but the problem is that there are generally four factors affecting the speed of a network: speed, bandwidth, reliability and latency. Different applications will be more sensitive to one or the other, so we firstly need to understand what the most important thing is, and how the factors differ between satellite and ship-to-shore transmission routes.
    Latency IS really bad, enough so that the web app is unusable due to response time when the ship is out at sea, but it works great anywhere on land.

    We've tried just about everything, we're caching and compressing as much as possible. It's not the amount of data coming across the line, our transfers are pretty short, and the load time for the page while not super, definitely isn't our main bottleneck, so it's not speed. We're not sending much concurrently, so I can basically rule out bandwidth. I didn't see any indicators of a reliability problem, but I don't know how to rule it out with firebug, and it wasn't horrifically evident (all the packets were sent and received eventually). There is a long wait regardless of the size of the data being sent. That points to latency in my book.

    The only inherent difference (other than one is push and the other a pull) between SMTP and HTTP transport is that HTTP must always be a direct connection, (unless proxies are involved) whereas SMTP is less reliable as it relies on each hop getting it nearer to its destination which is only theoretically true.
    The big difference here is our sending mechanism. One goes out over satellite, the other goes out over radio. Radio good, satellite bad. We can send messages back and forth over email in close to real time. We can't do that with a simple ajax transfer.

    Are you actually
    Am I actually what? Wait!?! You KNOW!?! Now you must die.

  6. #6
    Join Date
    May 2010
    Posts
    168
    I should also note:

    Even if speed was a factor, and I'm sure using sat comm it is, because we're talking 80s-90s tech, it's not going to improve.

    We don't want to lock down a radio freq for internet comm even if we could do it, at that point it would probably open a big pandora's box of new issues. Too many boats to probably pull off wrt broadcasts, and some regulatory agency would probably scream bloody murder. The options not on the table.

    We're actually thinking about displaying the request on screen and copying the request from there to an mua. It might actually be faster...yes, it's that bad. We're trying to eliminate that middle step if we can though, hence my question. We'd then process it on the server and notify the port authority from server side.
    Last edited by janusmccarthy; 02-24-2011 at 06:45 AM. Reason: added some notes in the last paragraph

  7. #7
    Join Date
    Jan 2005
    Posts
    369
    Dunno what happened to the last paragraph of my last post...

    Anyway, sounds like you might be best to try and set this up as an actual email message, though that is obviously not trivial. If your security allows it, then you could probably write a little Java application (not an applet) to send a text-based email over your existing connection, if that is using SMTP (A bit harder if you are using MAPI or whatever)
    The trade off that you get is that email is very rarely 100% reliable.

    Getting back closer to what you originally suggested, is the radio link a direct ship-to-shore transfer, or not? If it is, then only firewall/proxy security would prevent you from doing HTTP on port 25.

  8. #8
    Join Date
    May 2010
    Posts
    168
    Yeah, that's what I thought might be necessary. Actually, not that hard to send a text based email via program. We might look into a java app, though I doubt it, one of the reasons we went with a web ui was the lack of software updates. Still webstart may be an applicable solution here.

    Radio is not guaranteed to be a direct ship-to-shore xfer due to LOS on radio signals. There may be other ships or ground station relays that act as repeaters, signal might also be bounced off the atmo if the distance is great enough.

  9. #9
    Join Date
    Jan 2005
    Posts
    369
    I know a bit about radio, from being a signaller in my formative years, wasn't sure how far off-shore you needed to cover. So, ships that act as repeaters, are they directly repeating the radio signal (bit for bit) or do they act as SMTP relays (MTA's)? If it is the latter, then you can't just use port 25 to transmit HTTP but equally if it is the former, then the latency is going to get pretty bad, isn't it?

  10. #10
    Join Date
    May 2010
    Posts
    168
    You know, I'm not 100&#37; sure. We're getting into areas that are neither my specialty, nor I'm not fully aware of.

    I'd almost say it'd have to be a direct repeat, but I'd have to confirm. I just can't see you being able to build any of the next hop rules reliably out at sea.

    As for just routing HTTP over 25, it's not going to happen. I think the reason that it's used for email is entirely because it's few and far between short bursts. I don't think it could handle that many boats on the same freq otherwise.

    It looks like I'm pretty much stuck with them transferring it themselves or moving away from the web client. Bummer.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles