Same App and multiple sock RRS feed

  • Question

  • Hello,

    Please, let me know if there would be some limitations to the traffic volume when same App using multiple sockets will connect to another over the same port#?
    I pretty much sure there wouldn't, but I have some hesitation for the same App and multiple sock, not about multiple tasks and socks..

    "I = I + 1" .. Isn't it boolshit?

    Friday, November 1, 2019 11:32 AM

All replies

  • found on SO: What is the difference between a port and a socket?
    "There can only be one listener socket for a given address/port combination."
    so what you describe in your picture is not possible.
    Friday, November 1, 2019 11:58 AM
  • Thanks for your reply.

    Pls, re-read my Q.
    Listener just listens, my diagram is about connected sockets.

    "I = I + 1" .. Isn't it boolshit?

    Friday, November 1, 2019 12:09 PM
  • You can have any # of clients on a single socket limited only by the OS rules. A single app can have any # of sockets up to the limits set by available ports and the OS. So academically there is no limit.

    However real world implementations will have a limit. To begin with your server would need to support all those clients therefore it needs to be able to handle multiple clients at the same time. If the connections are persistent (they generally are) then that means you're going to need some sort of threading mechanism because each client will need to be run separately. If you try to run them all on the same thread then one slow client will stall everyone. However if you create a separate thread for each client you will eventually run out of threads. At one time you were limited to about 2K threads per process. This was because of the minimum stack space allocated for each thread and the limits of x86. With newer OS versions and x64 you can probably go higher but unless you're building a web server then you are going to run into issues at some point.

    Since you cannot spawn separate threads for each client you're going to need some sort of thread pool (not the .NET thread pool mind you). The # of simultaneous connections will be limited to how many threads you allow in your pool. When you get a request on a socket (whether a new client or a message on an existing client) you'll need to push that work to one of your threads in the pool. When the message is handled the thread is returned to the pool. This is exactly how web servers work by the way. The more threads you allow the more your app can grow out of control but the more simultaneous connections you can support.

    Bear in mind this is per client so a single app that has a single socket and a max of 100 in the pool can handle 100 simultaneous requests from that client. If you have 10 clients connected then it could handle all 10 at once (barring the limits of the processor and any shared data). If you have 1000 though then only 100 can be handled at once. If you wait too long then the socket times out. If you then expand this to multiple sockets (say 10) with each having 10 clients then all can communicate at the same time but if you add just one more client then you cannot handle them all at once.

    Michael Taylor

    Friday, November 1, 2019 2:09 PM
  • @CoolDadTx he specifically asked for multiple sockets listening on the same port (see left part of his picture).
    you make it sound like this is possible?
    Friday, November 1, 2019 2:26 PM
  • The OP can clarify what they want but that is not how I interpret it or their diagram. A single app can connect to the same port any # of times. The only limit is that there can be one listener on a port. However it is important to recognize that a socket and a listener are not the same thing. Each time a client connects to a port a new socket is created. Hence a socket represents a connection to a port from a client. The diagram is showing a server having multiple sockets (one for each client connection) as does the client. Nowhere in this diagram is the listener mentioned at all. The assumption is that there is one listener (e.g. TcpListener) but there can be any # of sockets open on the same or other machines.

    Michael Taylor

    Friday, November 1, 2019 2:46 PM
  • Hi there,

    Thank you for your comment.
    Yeah, you right (CoolDaddy) I remember there are always limitations for number of the simultaneous connections in most settings at most servers.. ASP.. MS SQL and so on..
    In regards to Database connections pool it helps to save time for establishing a new connection for a requested DB request from one of working threads.. I had developed some app where about 60 clients at random time request a DB DML operation and they just ask for any free "already connected" channel to execute their request. There were about 10 in pool with KeepAlive to satisfy all clients.. just some kind of banking soft for front office and short transactions..

    So, yeah, my question was exactly about some programming practice in real life. how it works if one App has connected to the srver thru the same port under c#.NET.. you know maybe there are some undetectable or unstable behavior of such bunch of threads having different traffic volumes..

    In other words - how robust would be such solution in practice.. Just as the example, say, if one thread rends sound data another receives , and next another sends documents, or forth receives them.. fifth - takes video control and so on.. would it be ok or better to dispatch data into separate port according to its mission/"destiny"..?

    "I = I + 1" .. Isn't it boolshit?

    Friday, November 1, 2019 8:56 PM
  • The diagram is showing a server having multiple sockets (one for each client connection) as does the client.

    One client and One server.. one PORT# and many sockets.
    Another client - another bunch of sockets over the same port# )))

    "I = I + 1" .. Isn't it boolshit?

    Friday, November 1, 2019 9:02 PM
  • "In other words - how robust would be such solution in practice.."

    Given your specific example this would be more an application question because you are prioritizing the work based upon the type of message. Since sockets are generally send-receive based all messages would have the same priority. If your app is dealing with different "priority" messages then using the same socket on the client side isn't going to work out. You'll need separate sockets. Does it matter whether they use the same port or different connections to the same port? Probably not. Especially if the server is going to handle all the messages (regardless of port) anyway.

    From a configuration viewpoint it also might be confusing to use different addresses for different sets of messages. For example having clients connect to port 50 for video, port 60 for documents and port 70 for everything else means clients would need to manage 3 different client connections if they wanted to support all 3. Using a single connection would allow the client to determine what is most important and create separate sockets if they need to prioritize. For example if I'm building a chat program then I'd like a single address to use. If I want to send files back and forth I might create a temporary second socket to send the file while using the original socket for chat. However maybe I don't care about stalling the chat while the file uploads. In that case I'll just stick with the first socket. Completely up to the client.

    On the server side things can be different though. If your messages are heavy and require extensive CPU resources then you will probably want to handle them differently. For example your handler code might determine that this message is high priority so it pushes it to a priority queue that will work it immediately. However another message may be low priority so you push it to a queue that only processes when there are no higher priority messages waiting. 

    Michael Taylor

    Friday, November 1, 2019 9:10 PM
  • > One client and One server.. one PORT# and many sockets.
    > Another client - another bunch of sockets over the same port# )))

    I'm not sure what you're trying to say here, but I suspect you misunderstand how TCP works.

    A TCP server advertises one well-known port by opening a socket and listening.  A web server is a good example -- one socket listening on port 80.  However that socket is only used for the initial contact.  When the connection is accepted, a new socket is created, and all of the communication for that exchange happens over that new socket.

    On the client side, every connection is a separate socket.  If you want 10 connections to a web server, you create 10 sockets, and all of them connect to port 80 on the server.

    Given that, what are you trying to do?

    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Sunday, November 3, 2019 3:33 AM