✅ TCP Socket incorrectly reading
I'm newer to messaging around with internet protocol, sockets, and everything in relation, so pardon any faulty language.
I'm currently attempting to have sockets from multiple other programs on other networks and ports all connect to a single port on my machine, though all in different channels. They're all successfully connecting and allowing messages, but it appears that my device is failing to differentiate between the sources. When reading, they can all access each-others stream. I've tried both using sockets and TCPListeners.
How would I go about resolving this or implementing something more effective?
47 Replies
do you have a code sample of your server? for TCP you should be ending up with an object for each device connected that encapsulates each connection
would also like examples/clarification on "they can all access each-others stream" because that doesn't sound like something that's possible
Yes, give me a moment
This is the area of my accepter/listener, where I accept incoming clients, create a new
YuiCenterClient ( a handler for engaging in sending and receiving for that client specifically ), and then start it
and the issue is with the events i assume?
Yeah
One moment, I was grabbing more information for you
This is a snippet from the console of the server receving the connections and subsequent messages.
I have an opposing program connect to the server's acceptance port from three different ports ( 7223, 7224, and 7225 ), and then send one message from each port. Of course, you can see here that my acceptance program sees them all as coming from port 7223.
I have one more piece of information to clarify, I'll post that here shortly.
yes, because they are all coming from port 7223
the port on the sending side isn't relevant
what type is
c?c is a
YuiCenterClientwhere does the issue with not being able to tell which client is which come in?
you should have a different one of those objects for each connection, i'd assume
I should also note that the port being listened on/accepted from is
7222
I do, yes
Each connection, or client, has their own YuiCenterClient
And of course, the YuiIp is just an address and port.This is a snippets from the "read cycles" that lie in every
YuiCenterClient. I don't know if using a StreamReader would help in this scenario or not, but I can attempt to introduce one if it might make a difference.
The Ip and port in this snippet is derived from the Ip of the client that read the transmission.
i mean, one problem is that none of this code is async
which may or may not be related to your problem
What impact would that have, if you don't mind me asking?
I guess I should ask instead, what's the difference?
well, how are you currently calling the code that's reading from each client?
the difference is that for example, if you're trying to read all your clients in a loop it can only read one at a time and if one blocks you won't get to reading the other ones
Under each "Start" method in each client, it begins the read cycle on a new thread.
that answers my question, that works but fwiw that's a more outdated way of handling it
I'm using a
for () statement to loop it, killing the loop if the client seems to be disconnected from the stream for any reason.modern code uses async/await, tasks, etc
it seems like the problem is stemming more from assuming the remote ip/port can be used as a stable identity for a client
if you care which client is which you'll probably want to implement a system that allows them to identify themselves when they connect
Hmm, I assumed that reading from the specific client's stream would only provide me the informatino being sent from that specific port, not just all information headed to my port.
that is correct, each socket will only have data from one connection
Well, so far, the identification seems to be working perfectly fine. Each of the clients has a successful label on them.
i guess i'm confused, where are you losing the ability to tell which is which?
the only thing i really see is that you're wiring all clients into the same event handlers
I'll see if I can grab some more info for you
Here is a new snippet from the console of the listener. Here you can see a little clearer that each new connection is being successfully identified.
Upon connecting, each read cycle is subsequently activated, and they all read from their own streams, as shown in this message.
That is where I'd say I may be losing the ability to tell which is which.
So, when they receive bytes, they trigger their own "bytes received" event, in which they provide their own ip as a way to say "I'm the one who received it!"
Which is why I know that, in the console snippet above, the
YuiCenterClient that successfully read the messages from all senders was the one attached the sender with the port 7223.
While I await your response, I'm going to make everything async, and then I'll use a stream reader and see if that has an impact.i would suggest try solving one problem at a time
what is the identity of a client for you?
what code is in the event handler that's printing these messages?
Are you asking what I mean when I say "client"?
I may be misunderstanding your question, but each event handler only invokes the events using the information it's been provided.
like the code that is printing the part of your log that's in brackets
what are the properties of the 'source' that you want/need to use to differentiate between them
like for example do your connections have an id
basically, i'm trying to know the whole chain of code from a client receiving data and it getting printed out in the console in your screenshot
It's printing the ip of the
YuiCenterClient that read it. I'll provide another screenshot of the specific printing method/event real quick.
It receives the
YuiIp of the YuiCenterClient that successfully read the stream.
That specific event is invoked right after the reading, this screenshot shows the minimal process at the bottom (
Client is the TcpClient that is returned upon accepting a connection )
Each connection is only identified by the
YuiIp ( address and port ) attached to it. Each YuiCenterClient is quite minimal, the only variables included are the YuiIp, and the TcpClient returned upon accepting the connection.
At the moment, they all share my address as I'm running them locally for experimenting, but they all have a different port ( 7222 for the listener, and 7223, 7224, and 7225 for the senders ).to me this seems odd
a socket connection is bidirectional
why would you have a bunch of ports allocated for "senders"
or maybe i didn't understand your purposes, i will admit my mind is occupied
Sorry for any misunderstanding on my part, and thank you for giving your time to help.
In summation, the point of this entire program is to be able to allow one program to act as a hub for accumulating the streams of anyone who connects to it. Of course, in a real world application, I would likely not have two ports on the same device trying to access one port on the listening program, but I need it to still work in that case.
The "senders" are representations of other systems that would be attempting to connect with the listener from various networks and/or devices.
Also, I added a line to write the
RemoteEndPoint of the TcpClient upon successfully reading, and it is reading from the 7223 client.
I, have both fortunately and unfortunately realized the issue on my part.
Fortunately, it's now fixed, but unfortunately it was a minor issue that could have been resolved much quicker upon a more effective evaluation.
The sender program was simply sending them all from the same port.
I apologize for all of the confusion, and I much appreciate both of your time and effort :)why are you worried about ports, once the connection is established then it's good, you have your object to read/write to it
i would rather give senders a name
The ports act a form of identification for me.
Well, in more specific use cases, giving them a name is definitely more optimal, this is a very bare-bones system at the moment though, so storing their address and port act as a form of identification.
thinking about them in an abstract way, even if only by an id like 1, 2, 3, helps rather thinking about them in a physical way like ip:[remote] port
for me
once you are done with the physical part it helps "forgetting" it, in the sense of leaving it in an underlying layer
also what does this
hub for accumulating the streamsexactly means? clients send to hub, hub sends to "next" device? so you are adding the streams? but does other direction work too? in that case would you be demultiplexing or broadcasting?
I guess broadcasting is the right term? I'm not fully educated on this topic, but I just mean that the hub is something that other programs ( specific ones, not just anyone ) would connect to for whatever purpose necessary, then bidirectional communication can be initiated.
ok, so now the ports thing
is it clear to you that there are a local port and a remote port in a connection?
and that one of those ports will be the server's listening one and the other usually a random one?
In one of the messages above, I mentioned that I fixed it, and that it was a minor issue that I shouldn’t have missed.
Thank you so much for your time 
ah ok
if there are no more issue you should
/close thisOh, sorry! I was unaware of how this works, this was my first time asking for help here. Thank you so much!