   Simplest internet-based client-server communication
  Hi,I have no clue about network programming, but I'd like to implement a very simple client-server application, where:-Under Windows-The communication has to go through internet (not local network)-The client just sends a small packet of data-The server replies to that packet with another small packet-If possible, I don't want to have to install any additional Windows services/packages-Not required to be fastI once used the Simple Socket Library to exchange data through a local network, but I don't know how to go about the internet and firewalls and and and...Could anyone point me into the right direction?Thanks!   
  Hello floatingwoods! I will try to answer your questions. :)Quote:-Under Windows-The communication has to go through internet (not local network)I recommend using Winsock. In fact, I would recommend using Winsock or the UNIX equivalent, BSD Sockets, for all your network programming needs. It supports communication over both local networks and over the internet.Quote:-The client just sends a small packet of data-The server replies to that packet with another small packetIn a situation where only a single exchange of information is required, implementing your service using the UDP protocol would probably be the easiest way to go. Note however that UDP does not guarantee delivery, so you might need to retransmit your request if you don't get a reply within a reasonable amount of time. The benefit of using UDP over TCP is that you don't have to go through the trouble of accepting connections and polling their sockets for data; all you have to do is recvfrom() your UDP server socket and reply to whoever sent the request.Quote:-If possible, I don't want to have to install any additional Windows services/packagesWinsock comes bundled with virtually all versions of Windows. Further, because of the way the Winsock API is implemented, it is easy to port your program to other systems that use similar APIs, such as Linux.For further information about socket programming, please refer to the excellent "Beej's Guide to Network Programming": http://www.beej.us/guide/bgnet/output/html/singlepage/bgnet.html. Be sure to check the notes for Windows programmers in the beginning, as Winsock requires some initialization functions to be called.Good luck!EDIT: For Winsock-specific information, have a look around MSDN.[Edited by - Windryder on May 11, 2009 2:03:37 AM];  The simpliest form of communication in my opinion would be over HTTP.But to achieve any sort of (pseudo) real time interactivity you will have to go against the grain slightly. For a realtime browser based chat service I used asynchronise requests to the server (ashx page (asp.net Handler)) and then kept the connection open for 30 seconds listening for any new data, I chose to limit it at 30 but you could in theory keep it open for a lot longer. I used custom HTTP headers for the command communication and JSON for the Data Interchange from the server. Technology Breakdown:Client - DHTML, &#106avascript, Async XMLHttpRequestCommunication - HTTP Data Interchange - JSON and textServer - ASHX, C#, .NET;  Windryder,thanks a lot for the very exhaustive reply!Does that mean that communicating through internet is done exactly the same way as communicating in a local network? So I'd basically just connect to an ip address, right? Will I have trouble with firewalls?Thanks Guthur,Actually I don't need any real-time interactivity, a few seconds delay would be fine too!   ;  Though I did mention Real-Time interaction its not really the main benefit, what it really does is over come the fact that HTTP is a request/response protocol. By keeping the connection open allows you a means to push data from the server in a timely manner; but it does kind of a abuse the nature of the protocol.Also HTTP communication is so easy you have a client app already, a browser.Windryder shows a better understanding of the deeper network layers than myself, I haven't gone that far yet.   ;  Yes, it will behave exactly the same on a local network as it would on the internet, as long as said network supports the Internet Protocol (find me one that doesn't :) ). You might have trouble with firewalls, but it's unlikely. Most NAT routers and firewalls will allow replies to UDP requests to pass without any issues.   ;  Thanks to both of you again. I got it almost working. Actually "Beej's Guide to Network Programming" is excellent for a start!   ;Quote:Original post by floatingwoodsThanks to both of you again. I got it almost working. Actually "Beej's Guide to Network Programming" is excellent for a start!Glad I could help -- I wish you the best of luck. :) And yes, Beej's guide is pretty damn comprehensive. ;  Well, I got everything up running now. Great! Thanks again for your helpThere are however two questions that remain:My client, after calling connect, waits for approximately 23 seconds if the server is not available. I read a lot about non-blocking operation and timeouts, but couldn't figure how to implement it. Here is what I have for the client until connection:WSADATA wsaData;struct hostent *hp;unsigned int addr;struct sockaddr_in server;if (WSAStartup(0x101,&wsaData)!=0)return;SOCKET conn;conn=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);if(conn==INVALID_SOCKET)return;if (inet_addr(connectionAddress.c_str())==INADDR_NONE)hp=gethostbyname(connectionAddress.c_str());else{addr=inet_addr(connectionAddress.c_str());hp=gethostbyaddr((char*)&addr,sizeof(addr),AF_INET);}if(hp==NULL){closesocket(conn);return;}server.sin_addr.s_addr=*((unsigned long*)hp->h_addr);server.sin_family=AF_INET;server.sin_port=htons(connectionPort);if(connect(conn,(struct sockaddr*)&server,sizeof(server))){closesocket(conn);return;}Another problem I encountered: if my server is behind a proxy, I cannot use the IP to access it. How is this normally handled?;Quote:How is this normally handled?A server has to be publically available somehow. Generally, that's done through reverse NAT or port forwarding through the firewall/proxy system. Another alternative, if there's a NAT firewall to traverse, is to do NAT punch-through with a separate introducer. There are several links in the Forum FAQ.