I was thinking about the concept of a software port which helps distinguish which internet packets belong to which application and i was wondering what similar construct does an app itself use to distinguish between two different connections that it might be attempting. For example, if an app X with asynchronous execution has initiated a connection on line 10 in its source code and then it starts another one on line 11 while the first connection is still ongoing what does it use to keep track of these connections?
I believe that depending on the connection type, there must be an identifier for it.
Take for example socket connections, assuming a client is using socket.io for initiating multiple connections with other processes, for every connection there is a unique id for it.
socket.on('connect', () => {
console.log(socket.id); // 'G5p5...'
});
This might be a little abstracted, but even on the low level, the same thing happens.
Related
I am trying to make 3 peer video chat using Webrtc in Flutter. A needs to see B and C. B needs to see A and C. C needs to A and B. I also use socket.io for signalling server. I used 2 peerconnection. two peer connection is successful. When I tried to connect the third one and tried to pass offer I got an error.
to execute 'createAnswer' on 'RTCPeerConnection': PeerConnection cannot create an answer in a state other than have-remote-offer or have-local-pranswer.
is my approach is bad for multiple peer connection?
A mesh of 3 users means each user sets up two connections, one to each of the other two users. At each client's end, these are two entirely different RTCPeerConnections, and you can't reuse candidates between them, as each candidate contains port numbers allocated specifically for the media and the target it is to be sent to.
If you know how to set up one connection, you know how to set up two. Just keep things separate.
just set 1 connection and try to use the direction: many to many
I would like to keep the Websocket connection alive for an undefined amount of time. The socket will ideally be sending data every so often but this is not assured, and I also would not like to make assumptions since a user can be in an idle state.
I have an object that stores references to all websocket connections. Would it be appropriate for me to schedule a function every x number of minutes? seconds? that basically iterates through all the connections, pings them and then discards those that haven't received pongs? Or do I need to enable a flag that automatically keeps the connection alive?
I am using the ws library on my server, but create websocket connections natively on the client.
There's no good way for you, on the client end of things, to know how many proxies, firewalls, NATs, etc occur in the network path from your client machine to the destination server. Any one of those could have its own separate idle timer. Using TCP keepalive may work, but only for the TCP session from your client to the next hop -- which may or may not actually be the end server.
Given the above, I would recommend that yes, you should ping your connected WebSocket sessions periodically. Whether you receive the pong from the server is, from the point of view of keeping your connections alive through that (possibly convoluted) chain of network middleboxes, irrelevant; you simply want to make sure that everything along the path sees some traffic flowing in order to reset their idle timers.
Obviously you want to trade off how often you ping your connected WebSocket sessions with how much overhead is incurred; pinging every 1 second would be a bit much, for example. You may need some fine-tuning to determine, experimentally, just what a good ping interval is for your needs.
Hope this helps!
I am just starting to learn sockets and client/servers. I am not clear on the following concept. Assume non-blocking sockets.
Assume I have a server application, and I have 1000 clients trying to talk to it, I think it is very realistic. Assume the client and server talk via sockets.
1- Does this mean that with every client, there is a separate socket connection? (Do we have 1000 sockets, or one socket with 1000 connections?
2- Does every socket connection belong to a separate thread? If Yes, How can we limit number of threads as it can get out of control?
Assuming you're using TCP, then every connection is over a separate socket. The operating system allocates them using file descriptors.
When using a protocol like UDP, this need not be the case, and won't be unless you write the code to do make it happen.
Threading? It depends on how you build the server. You don't need threads to be a part of a server at all and you can (obviously) have multiple threads with just a single connection. One common way of doing things, however, is to hand the socket returned by accept() to a new thread, yes.
If you don't have an interest in threads--for example, if the server only performs very quick tasks and creating a thread is just wasting time--you can use select() to poll the sockets and determine which ones need attention. Some servers use a combination of threading and polling to try to maximize throughput.
I am trying to write a server side code for sending push notifications for my applications. As per Apple recommendation, I am planning to retain the connection and send push notification as required.
Apple also allows opening and retaining multiple parallel connections for sending push notifications.
"You may establish multiple, parallel connections to the same gateway or to multiple gateway instances."
For this purpose I would like to maintain a connections pool.
My question is what is the limitation of connections pool, or the number of persistent connections with APNS can I maintain?
Thanks for anticipated help.
Don't know if you're going to get a precise answer to this one. As large and dynamic a system as APNS is, it behooves Apple to be ambiguous about such a number; it gives them liberty to change it at will. I found a similar vagueness here.
From this discussion it appears a rule of thumb is 15 connections max
One suggestion is to have an open-ended pool where new connections can be created until they start being refused. Just an idea.
I agree with #paislee, I don't think you'll get a precise number. I'm opening over 20 distinct connections simultaneously and there are ok.
In order to help you with your test, use TcpView, where it is possible to see every opened connection.
Regards
I have this question asked in the Go mailing list, but I think it is more general to get better response from SO.
When work with Java/.Net platform, I never had to manage database connection manually as the drivers handle it. Now, when try to connect to a no sql db with very basic driver support, it is my responsibility to manage the connection. The driver let connect, close, reconnect to a tcp port, but not sure how should i manage it (see the link). Do i have to create a new connection for each db request? can I use other 3rd party connection pooling libraries?
thanks.
I don't know enough about MongoDB to answer this question directly, but do you know how MongoDB handles requests over TCP? For example, one problem with a single TCP connection can be that the db will handle each request serially, potentially causing high latency even though it may be bottlenecking on a single machine and could handle a higher capacity.
Are the machines all running on a local network? If so, the cost of opening a new connection won't be too high, and might even be insignificant from a performance perspective regardless.
My two cents: Do one TCP connection per request and just profile it and see what happens. It is very easy to add pooling later if you're DoSing yourself, but it may never be a problem. That'll work right now, and you won't have to mess around with a third party library that may cause more problems than it solves.
Also, TCP programming is really easy. Don't be intimidated by it, detecting a closed socket, and reconnecting synchronously or asynchronously is simple.
Most mongodb drivers (clients) will create and use a connection pool when connecting to the server. Each socket (connection) can do one operation at a time at the server; because of how data is read off the socket you can issue many requests and server will just get them one after another and return data as each one completes.
There is a Go mongo db driver but it doesn't seem to do connection pooling. http://github.com/mikejs/gomongo
In addition to the answers here: if you find you do need to do some kind of connection pooling redis.go is a decent example of a database driver that pools connections. Specifically, look at the Client.popCon and Client.pushCon methods in the source.