Bidirectional Networking

[Emanuele D'Arrigo]

On Dec 13, 11:13 pm, Bryan Olson <fakeaddr... at nowhere.org> wrote:
> Software firewalls will often simply refuse incoming connections. The
> basic protection of the garden-variety home router comes from "network
> address translation" (NAT), in which case TCP connections initiated from
> the inside will generally work, regardless of port, and incoming
> connections will fail.

Ok, I think I'm getting the picture here. So this means that in most
circumstances where the data flow from the server is frequent the
client initiates the connection, usually requests some initial data
and keeps polling the server periodically, issuing new requests. In
this context can the client simply keep the connection alive and
listen for new data from the server coming at any time rather than
actively issuing requests? Are there drawbacks to this strategy? I.e.
is there a limit to the number of simultaneous connections a server
can keep alive? I've noticed that the socket pages mention a 5
connections limit. Is that it? What if I want to make a virtual room
with 20 people connected simultaneously?

> > or would it be the responsibility of the user
> > to configure the firewall so that the application can receive a
> > connection?
>
> That can be a huge hassle. The first choice is for the application to
> conform to popular firewall policies, so no special configuration is
> required.

I agree, I'd rather have the user do nothing in this regard. I'm just
wondering how it's done with data intensive application where the
server needs to send new data to the client frequently. Does the
client just keep the connection live at all time for the server to
send stuff or does the client continuously open, sends a request,
receives data and closes the connection every time? Here I'm thinking
about an online game, with 100 players moving their avatars. Does the
client requests their position nearly every frame?

Manu