Click here to Skip to main content
15,358,528 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I want to be able to use a single socket if possible to subscribe to multiple events of the same type (but with different parameters) over the socket of the same type, in order to keep track of various data streams over the same socket if at all possible.

What I have tried:

I can use different sockets to connect to a host server, with each socket subscribing to one event. However, this seems like it is perhaps inelegant and/or inefficient.
Posted
Updated 2-May-22 7:16am
Comments
OriginalGriff 2-May-22 3:01am
   
This is not a good question - we cannot work out from that little what you are trying to do.
Remember that we can't see your screen, access your HDD, or read your mind - we only get exactly what you type to work with - we get no other context for your project.
Imagine this: you go for a drive in the country, but you have a problem with the car. You call the garage, say "it broke" and turn off your phone. How long will you be waiting before the garage arrives with the right bits and tools to fix the car given they don't know what make or model it is, who you are, what happened when it all went wrong, or even where you are?

That's what you've done here. So stop typing as little as possible and try explaining things to people who have no way to access your project!

Use the "Improve question" widget to edit your question and provide better information.

1 solution

I don't know what you mean by "events" and "parameters" in your question. But you mentioned data streams, so I assume you're using TCP, or something that runs on top of TCP.

A TCP socket usually communicates with one peer, from which it receives a single data stream. That stream can deliver a sequence of events and parameters, but you need to frame them (that is, decide where they begin and end). When you read() from the socket, you might receive multiple "messages" or only a partial message. If you're using a protocol that runs on top of TCP, it might help you decide where the events and parameters begin and end. If not, you need to buffer incoming data until you have complete events or parameters that you can pass along to your application.

It sounds like everything is arriving from the same host server. So far, so good. But if you're accessing different services simultaneously, it is quite likely that you need a separate socket for each one. To avoid that, the server would most likely have to support requests for different services over the same socket, and multiplex the messages from those services onto that socket when replying to you.

If you are sending your initial requests to the server to different well-known port numbers, you will almost certainly need to keep using separate sockets.
   
Comments
LF FF 2-May-22 18:31pm
   
Hi thank you for taking the time to write such a thoughtful response. To give a little more context, this is within the context of me as a client accessing a host to use an API. So there are some asynchronous events being subscribed to. I have found that having multiple sockets open keeps each asynchronous event isolated from each other, whereas they seem to interfere within a single socket....one of my concerns is where I run into a limit as to the number of sockets allowed (easy enough to test for though). It seems that my approach of having multiple sockets just to keep events in their own lane (so to speak) seemed dumb. But maybe it is just the way to go. I am talking about maybe having on the order of 200 sockets for the events.
Greg Utas 2-May-22 18:43pm
   
200 sockets is a lot of sockets for a client. That's like running a little server! But I can't really say without knowing more about what you're doing. I also write C++, not C#, though that may not be relevant here.

As far as "interference" on a single socket goes, the question is whether the server or your client is causing it. I'm guessing it should be possible to use a single socket. But to do so, you need to be able to forward an incoming event to the code that sent the request. Unless that event does something like echo an identifier that you sent with the request, forwarding it to the right place will be hard unless you know that a given event should always be routed to a specific requester and can hard-code this.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900