i am writing a peer-to-peer chat application in C and would like to extend it using TOR as transport medium. Since i have never used TOR before and i roughly know how it works; i have no idea how to achieve that.
By all means, both clients are listening for connection requests on a specific TCP port (defined by user). What do i have to do, so that e.g Client A connects to Client B (assuming both have TOR client installed)? Due to some research i found out that i have to connect to localhost:9050 where the TOR client is listening and then i think i have to craft a SOCKS4/5 pdu to connect to the proxy??
If that's right, could someone explain me this in detail? Furthermore are there any libs i can use for connecting to a socks proxy (for C, OS: GNU/Linux, BSD)?
Thanks in advance!
Related
Ok, so I understand that communication between a client computer and a server computer can be initiated in windows with the creation of a socket between the two computers, but every tutorial that I have seen depends on the End User knowing the IP address of the computer that they wish to connect to.
In local network LAN games, however, the clients somehow autodetect the server. How is this done? Does the client autocheck every possible IP, is there some sort of "GetDetectedIPs" api, etc?
Im looking for answers that can be implemented in standard WIN32 API in straight C. No MFC, .NET, or C++ please. Thank you.
The technique you need is called broadcasting. It's used, for example, in BOOTP and DHCP protocols.
Sending a packet with broadcast destination address results in it being received by all devices in LAN. Broadcast address is an IP address in which the host identification field is filled with ones:
bcast_addr = ~netmask | my_addr;
The discovery process is usually like follows:
The client sends a UDP datagram with broadcast destination address at specific port.
The server listens on this port and receives the datagram. Other computers discard it.
Server sends all the necessary info about itself to the client by a usual UDP datagram.
This is usually done with zero-conf. Microsoft version of it is Simple Service Discovery Protocol.
You could just let the client send an UDP packet to every IP in a specified range and let the server answer with another UDP packet.
Using C and the Winsock library (UDP), I made a client-server multiplayer game.
Now I would like to make it so clients can be connected directly to each other (for example in Warcraft III when someone hosts a game the other players connect directly to him), but I do not know and could not find information on how to do this.
For the most part - especially in today's unfortunate world where most clients are behind NAT firewalls and ISPs that block so many incoming connections - client/server programs such as what you're looking to do will route all traffic through the central server, which is "guaranteed" to be accessible from all clients.
Otherwise, you'll want to look into UPnP, and/or something like UDP hole punching to achieve access between clients that may be behind the constraints listed above.
I have a single client that is trying to connect to my main server using socket s1. The client needs to keep trying to connect to main server with s1, but at the same time connect and keep sending "trying" messages to my secondary server. Is it a good idea to create 2 sockets,reuse port and create 2 binds for those 2 sockets or there are better ways to achieve this? This is a client side and using C sockets. Thanks.
If your program is a client to multiple servers, use one socket per server. You don't need bind for a client socket at all, just connect.
I think you are using TCP socket( aren't you?). So one socket for connection is needed.
Then reuse port is not so important because your application is a client application, which is the part the start the connection. Any outbound port should be ok.
Because you can only call connect(2) once per stream-oriented socket, you really must use at least two sockets to make two simultaneous connections (or connection attempts).
You don't need to bind(2) anything on client ports, except in strange cases. (I'm thinking of the Sun RPC portmapper daemon, but thankfully it's been nearly a decade since I've cared about the portmapper daemon. Also rlogin needed to bind(2) as a client when using the host-authentication method, which was horrible.)
I've come across an interesting problem. Basically I have 2 mobile phones that are both behind NATs. I want to communicate directly between the 2 devices using UDP.
I know if I initiate a connection from the phones to a server then I can push data back down that connection to the phone (ie send it back from the same port that received the message to the same ip and port that it was received from). So I can easily communicate between the 2 devices by connecting both phones to the server. Then sending data to the server and having it re-routed back to the phones. This bypasses any NAT traversal issues I may come up against.
However I would rather just use the server to point the 2 devices at each other and then let them communicate directly. How would I go about doing this? Is it possible without using something like uPnP?
Any help would be much appreicated!
Edit: I found this document http://www.brynosaurus.com/pub/net/p2pnat/ It looks like hairpin translation is what I'm after but it doesn't look to be widely supported. I wonder how good mobile ISP's support for UPnP is?
What you're looking for is UDP hole punching, see e.g. http://en.wikipedia.org/wiki/UDP_hole_punching
The basic idea is simple, you tell each endpoint the ports to use, and they start sending udp packets. The NAT'ing devices will set up a traversal rule when they see the first outgoing packet, and then the next attempt from the other end will match this traversal rule.
You need a mediator server, so the clients can tell where they are. Then one opens a server by uPNP, and the other connects to it.
I am coding a very simple DHCP client in C. I have trouble deciding whether it should use UDP or TCP, what basic commands should it support. I think it should be able to get at least DNS, SMTP, POP3 server information from server.
What else do I need to know? Is there a basic DHCP C implementation available which can help?
You shouldn't have trouble "deciding" whether to use TCP or UDP, you should rely on the actual DHCP spec to determine what protocol is used. In fact, reliance on that spec will be more or less critical to implementing a DHCP client that does what it's supposed to do... since "what it's supposed to do" is defined in the spec.