incoming connection port 80

Discussion in 'Java' started by Erik, Mar 4, 2008.

  1. Erik

    Erik Guest

    I'm wondering how to accept connections (socket) if you are behind a
    router. Skype and
    uTorrent can handle this (by using port 80 or 443). How do these
    programs manage to accept
    connections if ports (accept port 80 and 443) are blocked?

    Thanks

    Erik
    Erik, Mar 4, 2008
    #1
    1. Advertising

  2. Erik

    Mark Space Guest

    Erik wrote:
    > I'm wondering how to accept connections (socket) if you are behind a
    > router. Skype and
    > uTorrent can handle this (by using port 80 or 443). How do these
    > programs manage to accept
    > connections if ports (accept port 80 and 443) are blocked?
    >
    > Thanks
    >
    > Erik


    uTorrent is just a Bit Torrent client.

    Bit Torrent connects out to a server, it does not accept incoming
    connections. Its incoming connections are not low number ports (80 or
    443) and have to be specifically enabled on the router/firewall or it
    won't work well.

    I didn't look up Skype, I assume it is similar. It connects out to a
    server. It probably maintains an open connect so a server can reply
    back when a call comes in.
    Mark Space, Mar 4, 2008
    #2
    1. Advertising

  3. Erik

    Erik Guest

    On 4 mrt, 19:55, Mark Space <> wrote:
    > Erik wrote:
    > > I'm wondering how to accept connections (socket) if you are behind a
    > > router. Skype and
    > > uTorrent can handle this (by using port 80 or 443). How do these
    > > programs manage to accept
    > > connections if ports (accept port 80 and 443) are blocked?

    >
    > > Thanks

    >
    > > Erik

    >
    > uTorrent is just a Bit Torrent client.
    >
    > Bit Torrent connects out to a server, it does not accept incoming
    > connections. Its incoming connections are not low number ports (80 or
    > 443) and have to be specifically enabled on the router/firewall or it
    > won't work well.
    >
    > I didn't look up Skype, I assume it is similar. It connects out to a
    > server. It probably maintains an open connect so a server can reply
    > back when a call comes in.


    I don't know if I completely understand you, but Skype indeed has an
    connection
    with a central server, but when someone tries to call you, he must be
    able to
    connect to you. In the Skype option menu you can specify a specific
    port for the incoming
    connection, but you can also specify to use port 80 or port 443 as
    alternative. What
    method is behind this?

    Erik
    Erik, Mar 4, 2008
    #3
  4. Erik

    Peter Duniho Guest

    On Tue, 04 Mar 2008 10:55:05 -0800, Mark Space <>
    wrote:

    > Erik wrote:
    >> I'm wondering how to accept connections (socket) if you are behind a
    >> router. Skype and
    >> uTorrent can handle this (by using port 80 or 443). How do these
    >> programs manage to accept
    >> connections if ports (accept port 80 and 443) are blocked?
    >> Thanks
    >> Erik

    >
    > uTorrent is just a Bit Torrent client.
    >
    > Bit Torrent connects out to a server, it does not accept incoming
    > connections. Its incoming connections are not low number ports (80 or
    > 443) and have to be specifically enabled on the router/firewall or it
    > won't work well.


    If it doesn't accept incoming connections, then why do its incoming
    connections "have to be specifically enabled"? :)

    To the original poster: an application that has a listening TCP socket
    does indeed require that the router _somehow_ be configured to forward
    connection requests to that socket. The two most common techniques
    involve manually configuring the router or using the "universal
    plug-and-play" protocol (by which a network application can obtain
    specific information from the router and/or configure the router to do
    specific forwarding).

    Many routers support "port triggering", by which the router watches
    outbound traffic and if it notes a network client using some particular
    port (either locally or, more commonly, in the remote address), it
    automatically enables forwarding to that client temporarily on some other
    specified port or ports (which may include the original outbound port).
    Specifics on this vary from router to router.

    You may also want to Google "nat hole punching". It's more reliable when
    used with UDP than TCP (different techniques are used with each, and doing
    it using TCP requires lower-level access than sockets normally give you),
    and in either case it's not 100% reliable as it depends on undocumented,
    arbitrary behavior on the part of the router. But depending on how
    important it is to solve the problem, it's something you might consider.

    Note that if the router has literally "blocked" the ports, then the answer
    is "you don't". Typically, the ports are only "blocked" in that the
    router doesn't know who to forward the traffic to. This is addressable as
    described above. But if someone's actually configured the router to not
    allow traffic on those ports to pass, then the only thing that will allow
    traffic on those ports through is to reconfigure the router so that it's
    no longer blocking traffic on those ports.

    Finally note that a "router" is not the same as a "firewall". Sometimes
    the two functions are combined into a single device, but a firewall's job
    is specifically to block traffic. Either it's blocking traffic on
    specific ports or it's not. If it's not, you have nothing to do, and if
    it is, nothing you can do short of changing the firewall configuration is
    going to unblock the ports. Obviously, changing the firewall
    configuration is not something that would be done automatically by a
    software client without any user intervention. Otherwise it wouldn't be
    much of a firewall. :)

    Pete
    Peter Duniho, Mar 4, 2008
    #4
  5. Erik

    Erik Guest

    On 4 mrt, 20:35, "Peter Duniho" <> wrote:
    > On Tue, 04 Mar 2008 10:55:05 -0800, Mark Space <>
    > wrote:
    >
    > > Erik wrote:
    > >> I'm wondering how to accept connections (socket) if you are behind a
    > >> router. Skype and
    > >> uTorrent can handle this (by using port 80 or 443). How do these
    > >> programs manage to accept
    > >> connections if ports (accept port 80 and 443) are blocked?
    > >> Thanks
    > >> Erik

    >
    > > uTorrent is just a Bit Torrent client.

    >
    > > Bit Torrent connects out to a server, it does not accept incoming
    > > connections. Its incoming connections are not low number ports (80 or
    > > 443) and have to be specifically enabled on the router/firewall or it
    > > won't work well.

    >
    > If it doesn't accept incoming connections, then why do its incoming
    > connections "have to be specifically enabled"? :)
    >
    > To the original poster: an application that has a listening TCP socket
    > does indeed require that the router _somehow_ be configured to forward
    > connection requests to that socket. The two most common techniques
    > involve manually configuring the router or using the "universal
    > plug-and-play" protocol (by which a network application can obtain
    > specific information from the router and/or configure the router to do
    > specific forwarding).
    >
    > Many routers support "port triggering", by which the router watches
    > outbound traffic and if it notes a network client using some particular
    > port (either locally or, more commonly, in the remote address), it
    > automatically enables forwarding to that client temporarily on some other
    > specified port or ports (which may include the original outbound port).
    > Specifics on this vary from router to router.
    >
    > You may also want to Google "nat hole punching". It's more reliable when
    > used with UDP than TCP (different techniques are used with each, and doing
    > it using TCP requires lower-level access than sockets normally give you),
    > and in either case it's not 100% reliable as it depends on undocumented,
    > arbitrary behavior on the part of the router. But depending on how
    > important it is to solve the problem, it's something you might consider.
    >
    > Note that if the router has literally "blocked" the ports, then the answer
    > is "you don't". Typically, the ports are only "blocked" in that the
    > router doesn't know who to forward the traffic to. This is addressable as
    > described above. But if someone's actually configured the router to not
    > allow traffic on those ports to pass, then the only thing that will allow
    > traffic on those ports through is to reconfigure the router so that it's
    > no longer blocking traffic on those ports.
    >
    > Finally note that a "router" is not the same as a "firewall". Sometimes
    > the two functions are combined into a single device, but a firewall's job
    > is specifically to block traffic. Either it's blocking traffic on
    > specific ports or it's not. If it's not, you have nothing to do, and if
    > it is, nothing you can do short of changing the firewall configuration is
    > going to unblock the ports. Obviously, changing the firewall
    > configuration is not something that would be done automatically by a
    > software client without any user intervention. Otherwise it wouldn't be
    > much of a firewall. :)
    >
    > Pete


    Thanks for your answer :).

    What I'm trying to do is to create a Java applet which can receive an
    incoming
    connection, so a connection is enstablished between a program and the
    applet (which
    must be able to accept the connection). Is this possible (to bypass
    the router (not the firewall!)) and if it's possible, how?

    Thanks

    Erik
    Erik, Mar 4, 2008
    #5
  6. Erik

    Mark Space Guest

    Peter Duniho wrote:

    > If it doesn't accept incoming connections, then why do its incoming
    > connections "have to be specifically enabled"? :)


    BitTorrent first connects out to a central server, and starts the
    download. After this, it has some parts of the file and it will start
    accepting requests for parts of the file, but it has to be downloading
    first. It doesn't accept connections if it isn't connected to a server yet.

    This two step process is, frankly, stupid in my opinion.
    Mark Space, Mar 4, 2008
    #6
  7. Erik

    Peter Duniho Guest

    On Tue, 04 Mar 2008 11:43:52 -0800, Erik <> wrote:

    > Thanks for your answer :).


    You're welcome.

    > What I'm trying to do is to create a Java applet which can receive an
    > incoming
    > connection, so a connection is enstablished between a program and the
    > applet (which
    > must be able to accept the connection).


    Assuming that your use of the word "connection" here implies TCP, and
    assuming that an applet is allowed to create a TCP socket that listens,
    then this should be possible. Note that I don't know enough about the
    limitations of an applet to answer that particular question. If Java
    blocks that sort of operation for applets, then you can't do it.

    > Is this possible (to bypass
    > the router (not the firewall!)) and if it's possible, how?


    Assuming applets are allowed to do that sort of thing, it's possible, and
    my previous post explained how, at least to the extent that I think might
    be appropriate in a Java programming newsgroup. There's plenty of
    information in there that should allow you to find the specific details
    via Google and/or in a newsgroup that more specifically deals with network
    programming.

    Pete
    Peter Duniho, Mar 4, 2008
    #7
  8. Erik

    Christian Guest

    Erik schrieb:
    > On 4 mrt, 20:35, "Peter Duniho" <> wrote:
    >> On Tue, 04 Mar 2008 10:55:05 -0800, Mark Space <>
    >> wrote:
    >>
    >>> Erik wrote:
    >>>> I'm wondering how to accept connections (socket) if you are behind a
    >>>> router. Skype and
    >>>> uTorrent can handle this (by using port 80 or 443). How do these
    >>>> programs manage to accept
    >>>> connections if ports (accept port 80 and 443) are blocked?
    >>>> Thanks
    >>>> Erik
    >>> uTorrent is just a Bit Torrent client.
    >>> Bit Torrent connects out to a server, it does not accept incoming
    >>> connections. Its incoming connections are not low number ports (80 or
    >>> 443) and have to be specifically enabled on the router/firewall or it
    >>> won't work well.

    >> If it doesn't accept incoming connections, then why do its incoming
    >> connections "have to be specifically enabled"? :)
    >>
    >> To the original poster: an application that has a listening TCP socket
    >> does indeed require that the router _somehow_ be configured to forward
    >> connection requests to that socket. The two most common techniques
    >> involve manually configuring the router or using the "universal
    >> plug-and-play" protocol (by which a network application can obtain
    >> specific information from the router and/or configure the router to do
    >> specific forwarding).
    >>
    >> Many routers support "port triggering", by which the router watches
    >> outbound traffic and if it notes a network client using some particular
    >> port (either locally or, more commonly, in the remote address), it
    >> automatically enables forwarding to that client temporarily on some other
    >> specified port or ports (which may include the original outbound port).
    >> Specifics on this vary from router to router.
    >>
    >> You may also want to Google "nat hole punching". It's more reliable when
    >> used with UDP than TCP (different techniques are used with each, and doing
    >> it using TCP requires lower-level access than sockets normally give you),
    >> and in either case it's not 100% reliable as it depends on undocumented,
    >> arbitrary behavior on the part of the router. But depending on how
    >> important it is to solve the problem, it's something you might consider.
    >>
    >> Note that if the router has literally "blocked" the ports, then the answer
    >> is "you don't". Typically, the ports are only "blocked" in that the
    >> router doesn't know who to forward the traffic to. This is addressable as
    >> described above. But if someone's actually configured the router to not
    >> allow traffic on those ports to pass, then the only thing that will allow
    >> traffic on those ports through is to reconfigure the router so that it's
    >> no longer blocking traffic on those ports.
    >>
    >> Finally note that a "router" is not the same as a "firewall". Sometimes
    >> the two functions are combined into a single device, but a firewall's job
    >> is specifically to block traffic. Either it's blocking traffic on
    >> specific ports or it's not. If it's not, you have nothing to do, and if
    >> it is, nothing you can do short of changing the firewall configuration is
    >> going to unblock the ports. Obviously, changing the firewall
    >> configuration is not something that would be done automatically by a
    >> software client without any user intervention. Otherwise it wouldn't be
    >> much of a firewall. :)
    >>
    >> Pete

    >
    > Thanks for your answer :).
    >
    > What I'm trying to do is to create a Java applet which can receive an
    > incoming
    > connection, so a connection is enstablished between a program and the
    > applet (which
    > must be able to accept the connection). Is this possible (to bypass
    > the router (not the firewall!)) and if it's possible, how?
    >
    > Thanks
    >
    > Erik

    A standard way would be to use UPnP protocol to open up a port.

    Everything else is more sophisticated.. like tricking the router into
    believing a connection was created .. probably not what you want (hole
    punching like told above)

    As a sidenode port 80 and alike are often used to trick admins/isps that
    don't work with level-7 filters but just block unwanted traffic by port.
    Christian, Mar 4, 2008
    #8
  9. Erik

    Peter Duniho Guest

    On Tue, 04 Mar 2008 11:51:18 -0800, Mark Space <>
    wrote:

    > Peter Duniho wrote:
    >
    >> If it doesn't accept incoming connections, then why do its incoming
    >> connections "have to be specifically enabled"? :)

    >
    > BitTorrent first connects out to a central server, and starts the
    > download. After this, it has some parts of the file and it will start
    > accepting requests for parts of the file, but it has to be downloading
    > first.


    That's not true. You can seed a file that you've already downloaded,
    without downloading anything more.

    > It doesn't accept connections if it isn't connected to a server yet.


    Well, downloaders need a way to find you. If you don't contact the
    central server, how will they know you're seeding? So yes, the client
    does need to make an outbound connection to some server before it can
    receiving inbound connection requestions.

    In any case, I think you missed the joke, which had nothing to do with any
    of the above.

    Pete
    Peter Duniho, Mar 4, 2008
    #9
  10. Erik

    Erik Guest

    On 4 mrt, 21:56, "Peter Duniho" <> wrote:
    > On Tue, 04 Mar 2008 11:51:18 -0800, Mark Space <>  
    > wrote:
    >
    > > Peter Duniho wrote:

    >
    > >> If it doesn't accept incoming connections, then why do its incoming  
    > >> connections "have to be specifically enabled"?  :)

    >
    > > BitTorrent first connects out to a central server, and starts the  
    > > download.  After this, it has some parts of the file and it will start  
    > > accepting requests for parts of the file, but it has to be downloading  
    > > first.

    >
    > That's not true.  You can seed a file that you've already downloaded,  
    > without downloading anything more.
    >
    > > It doesn't accept connections if it isn't connected to a server yet.

    >
    > Well, downloaders need a way to find you.  If you don't contact the  
    > central server, how will they know you're seeding?  So yes, the client  
    > does need to make an outbound connection to some server before it can  
    > receiving inbound connection requestions.
    >
    > In any case, I think you missed the joke, which had nothing to do with any  
    > of the above.
    >
    > Pete


    But is it posible to create an applet which can accept an incoming
    connection if it's behind a router? And if it's posible, how is
    this done?
    Also I still don't realy get how Skype does this. When I'm running
    Skype
    (and I'm behind a router) I have the "use port 80 and 443 as
    alternatives
    for incoming connections" enabled and Skype can receive incoming
    connections (calls).
    How does Skype do this?

    Erik
    Erik, Mar 5, 2008
    #10
  11. Erik

    Peter Duniho Guest

    On Wed, 05 Mar 2008 02:54:03 -0800, Erik <> wrote:

    > But is it posible to create an applet which can accept an incoming
    > connection if it's behind a router?


    If it's possible to create an applet that can accept an incoming
    connection generally, then it's possible to do when it's behind a router.

    > And if it's posible, how is this done?


    I already wrote a post telling you how. I also already wrote a post
    telling you that I already wrote a post telling you how. Now I am writing
    a post telling you that I already wrote a post telling you that I already
    wrote a post telling you how.

    I think this is getting a little out of hand.

    Pete
    Peter Duniho, Mar 5, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Krishna

    Identify Incoming Phone Call

    Krishna, Dec 23, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    2,416
    Scott M.
    Dec 27, 2005
  2. Rick Strahl [MVP]
    Replies:
    2
    Views:
    381
    Teemu Keiski
    May 6, 2004
  3. Rick Strahl [MVP]
    Replies:
    1
    Views:
    377
    Natty Gur
    May 10, 2004
  4. Dave Smithz
    Replies:
    2
    Views:
    646
    MWells
    Jan 16, 2005
  5. saeed
    Replies:
    2
    Views:
    208
    Joe Smith
    Sep 7, 2004
Loading...

Share This Page