Winsock Peer to Peer using UDP and TCP
-
Hello, I've been working on an application that would allow a program to communicate over lan, using UDP and TCP. Here's a general flow of what I was thinking: 1. Send UDP Broadcast to subnet on a port that all applications will listen on (i.e. all listening on 59200) 2. The application running on other nodes, receive the broadcast and echo a UDP broadcast back. 3. Using the information obtained from the UDP echo, a TCP connection is opened and data is exchanged. 4. Connections remain open until an error occurs (this was a requirement of design.) Is such a design feasible, and if so how would it best be accomplished? I've been reading up on Winsock and MSDN articles on this, and have created client/server applications but have not found very much that would outline a peer-to-peer application like this. I would appreciate any guidance, or direction a resource that could further my understanding on this topic.
-
Hello, I've been working on an application that would allow a program to communicate over lan, using UDP and TCP. Here's a general flow of what I was thinking: 1. Send UDP Broadcast to subnet on a port that all applications will listen on (i.e. all listening on 59200) 2. The application running on other nodes, receive the broadcast and echo a UDP broadcast back. 3. Using the information obtained from the UDP echo, a TCP connection is opened and data is exchanged. 4. Connections remain open until an error occurs (this was a requirement of design.) Is such a design feasible, and if so how would it best be accomplished? I've been reading up on Winsock and MSDN articles on this, and have created client/server applications but have not found very much that would outline a peer-to-peer application like this. I would appreciate any guidance, or direction a resource that could further my understanding on this topic.
Well, first of all, what are you trying to accomplish and what are your requirements? If your application is supposed to work over internet, UDP broadcast is usually not a good option because most routers will not forward broadcasts (can you imagine how much traffic would be on the internet if every broadcast message was forwarded?). With your scenario, I'm not even quite clear on why you have the UDP piece at all? Why not just have a TCP/IP connection on a known port? Peer-to-peer simply means there isn't a man in the middle (or computer/server to be precise), that's just about every socket protocol unless you're using some sort of service in the middle.
-
Well, first of all, what are you trying to accomplish and what are your requirements? If your application is supposed to work over internet, UDP broadcast is usually not a good option because most routers will not forward broadcasts (can you imagine how much traffic would be on the internet if every broadcast message was forwarded?). With your scenario, I'm not even quite clear on why you have the UDP piece at all? Why not just have a TCP/IP connection on a known port? Peer-to-peer simply means there isn't a man in the middle (or computer/server to be precise), that's just about every socket protocol unless you're using some sort of service in the middle.
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN. The issue faced is that a specific address is needed for the TCP/IP connection, that will be the piece exchanged via UDP. I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
-
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN. The issue faced is that a specific address is needed for the TCP/IP connection, that will be the piece exchanged via UDP. I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
SD1208 wrote:
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN.
You mean so that they know about each other without having a set server and client? I still don't follow what you're trying to achieve. Why don't you describe functionally what you're trying to achieve instead.
SD1208 wrote:
I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
Multiple threads would probably be ideal if a program is expected to work as both a server and client.
-
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN. The issue faced is that a specific address is needed for the TCP/IP connection, that will be the piece exchanged via UDP. I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
If you are doing this on a company LAN, you should give your IT department a heads up. It is possible they have alerts set up on their monitoring software to notify them whenever there is UDP Broadcast activity on their network. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN. The issue faced is that a specific address is needed for the TCP/IP connection, that will be the piece exchanged via UDP. I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
Quote:
I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?
Maybe I am miss-understanding, but I suspect that SD1208 is not understanding the phrases client and server. Does this help any: Any application on any computer can take the server role or client role. Server in TCP/IP does not refer to a "SERVER" computer that is running a "SERVER" operating system. The server application must start first. It opens a port and listens for any client application. The client connects to a port already opened by a server. Then the two applications can chat.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/