I'm working on embedding Mongoose into an application, and I need to be able to have the app connect to a server when it starts up. How can I do this? On GitHub, I see examples for receiving connections, but none on how to initialize a connection with another one. Any ideas?
Mongoose is a web server. It is designed to accept incoming connections, not make outgoing ones.
If you want to make outgoing connections, the way forward will depend on what you are connecting to and what protocol(s) it may use.
If you want to make outgoing http or https connections, you could use libcurl.
If some other protocol you may be able to find an appropriate library. Or, you can use operating system layer socket APIs to make your own connection, and implement whatever protocol is required on top of that. Here is an example for Linux, for example.
Related
We have an existing legacy C++ app which uses TCP via Berkeley C sockets.
We need to continue using Berkeley sockets in our existing environment but for a second, new environment we need to use SSL/TLS.
I've programmed with openssl before but this application code is.... significant, not easy to change.
Is there a way to achieve SSL without making code changes? (networking, proxies etc)
The answer depends on your needs. To send HTTP requests, you can implement a proxy server that will redirect all incoming requests to their destination by adding ssl / tls functionality. For this method, most likely it will not be possible to find a solution "out of the box". I would recommend using Poco, ServerApplication, HTTPs Client session.
To use protocols that support a permanent connection, it is more logical to set up a secure tunnel, which will add ssl / tls to all incoming packets, and remove it from outgoing packets. For this method it is quite possible to find a solution out of the box. Try using the stunnel / ghostunnel from the recommendations. Also, this option can definitely be implemented using the same Poco library, or using low-level posix sockets and openssl encryption.
Both solutions can be set up on the secondary node by sending packets from the source server to the address of the new node, or on the local machine by sending packets to the loopback address.
I need to make some general way for my own peer-to-peer UDP or TCP communication between my own clients over internet, without creating own server.
I cannot just use XMPP for the communication because file transmit are necessary.
Do I understand the possible sequence of actions correctly?
Connect to some (or any?) XMPP server, using prepared existing XMPP account
Search for another my own client connected to XMPP and connect to it.
Resolve an unique public global internet (IP?) address or ID for each client (how?)
Exchange these addresses between clients
Make direct connection possible by some actions with clients' NATs
Connect clients directly p2p to each other using received unique addresses
Disconnect from XMPP server
Communicate via my own p2p connection
If the sequence is correctly, what specific actions do I need to do to resolve unique addresses, and to make an UDP or TCP connection then? How that can be done on c++?
Edit.
I've found nice answer here: Programming P2P application
Your situation is close to WebRTC: peers need a way to 1) discover each other ("signaling"), 2) set up a direct connection through NAT if needed. (STUN/TURN)
See this WebRTC infrastructure overview for a start, and ask more specific follow-up questions later.
I want to develop a Qt5/C++ client-server application using remote procedure calls (RPC).
Idea:
The server listens for incoming connections of multiple clients.
Clients offer a set of procedures/services the server can call in order to collect data from clients and inform other clients about changes.
And here is the catch:
The RPC libs i've seen so far seem to expect the server to offer a service the clients may call. But I want to do the opposite. Clients should offer services the server may call.
The direction is important, because I want to enable port forwarding on the server side only, not on the client side.
The libs I've checked are:
QtRpc2 (https://github.com/brendan0powers/QtRpc2)
grpc (http://www.grpc.io)
Questions:
Is there a reason these libs offer services on server side only?
Did I maybe only miss that part in the documentation?
Is there an RPC lib that does offer client side service offering?
gRPC supports bidirectional streaming, which may meet your needs.
Clients can open a long lived connection to a server, and then the server can "call" the clients by sending responses on the stream.
The client can respond by sending another message on the stream.
http://www.grpc.io/docs/tutorials/basic/c.html
I'm brand new to c++ and know next to nothing about web protocols or websockets, so this may seem ridiculous.
I make websites that are 100% ajax and want to incorporate websockets. Fastcgi++ is everything I could hope for for the ajax demands, but it doesn't have websockets, and I chose websocket++ over libwebsockets since websocket++ is more or less a simple #include, so I assumed that I could incorporate it into fastcgi++.
I think I've figured out fastcgi++, and it looks like most of the action happens in Fastcgipp::Request then Fastcgipp::Http::Sessions for session data http://www.nongnu.org/fastcgipp/doc/2.1/a00005.html; however, I think I have to do the same thing with websocket++'s server::handler for handling the websocket https://github.com/zaphoyd/websocketpp/wiki/Creating-Applications-using-WebSocket--, and now I'm lost at sea.
Enter my complete inexperience with c++: I think I have to use virtual inheritance, but I have no idea. Also, if I could even properly "subclass" both, how do I make sure that they don't run over each other?
Please show me a basic example of how websocket++ can use fastcgi++'s session management.
A WebSocket connection cannot be processed by an HTTP request/response workflow. In order to use something like fastcgi++ with both regular HTTP requests and with WebSocket requests it would need to have some way of recognizing a WebSocket handshake and piping that off to another handler instead of processing it as HTTP. I don't see an obvious pass through mode of that sort in its documentation, but I could be missing something.
If such a feature exists, WebSocket++ can be used in stream mode where it disables all of its network elements and just processes streams of bytes piped in from another networking library.
Some alternatives:
WebSocket++ supports HTTP pass through. This is essentially the opposite of what is described above. WebSocket++ would be used as the networking layer. It would process incoming WebSocket connections and would pass off HTTP requests to some other subsystem.
WebSocket++ and fastcgi++ could be run on different ports or different hostnames. This could be done in the same program or separate programs. With client side requests directed to the appropriate host/port.
Disclaimer: I am the author of WebSocket++
I'm not real hip on exactly what role(s) today's proxy servers can play and I'm learning so go easy on me :-) I have a client/server system I have written using a homegrown protocol and need to enhance the client side to negotiate its way out of a proxy environment.
I have an existing client and server system written in C and C++ for the speed and a small amount of MFC in the client to handle the user interface. I have written both the server and client side of the system on Windows (the people I work for are mainly web developers using Windows everything - not a choice) sticking to Berkeley Sockets as it were via wsock32 for efficiency. The clients connect to the server through a nonstandard port (even though using port 80 is an option to get out of some environments but the protocol that goes over it isn't HTTP). The TCP connection(s) stay open for the duration of the clients participation in real time conferences.
Our customer base is expanding to all kinds of networked environments. I have been able to solve a lot of problems by adding the ability to connect securely over port 443 and using secure sockets which allows the protocol to pass through a lot environments since the internal packets can't be sniffed. But more and more of our customers are behind a proxy server environment and my direct connections don't make it through. My old school understanding of proxy servers is that they act as a proxy for external HTML content over HTTP, possibly locally caching popular material for faster local access, and also allowing their IT staff to blacklist certain destination sites. Customer are complaining that my software doesn't recognize and easily navigate its way through their proxy environments but I'm finding it difficult to decide what my "best fit" solution should be. My software doesn't tear down the connection after each client request, and on top of that packets can come from either side at any time, basically your typical custom client/server system for a specific niche.
My first reaction is "why can't they just add my server's addresses to their white list" but if there is a programmatic way I can get through without requiring their IT staff to help it is politically better and arguably a better solution anyway. Plus maybe I'm still not understanding the role and purpose of what proxy servers and environments have grown to be these days.
My first attempt at a solution was to use WinInet with its various proxy capabilities to establish a connection over port 80 to my non-standard protocol server (which knows enough to recognize and answer a simple HTTP-looking GET request and answer it with a simple HTTP response page to get around some environments that employ initial packet sniffing (DPI)). I retrieved the actual SOCKET handle behind WinInet's HINTERNET request object and had hoped to use that in place of my software's existing SOCKET connection and hopefully not need to change much more on the client side. It initially seemed to be my solution but on further inspection it seems that the OS gets first-chance at the received data on this socket since when I get notified of events via the standard select(...) statement on the socket and query the size of the data available via ioctlsocket the call succeeds but returns 0 bytes available, the reads don't work and it goes downhill from there.
Can someone tell me of a client-side library (commercial is fine) will let me get past these proxy server environments with as little user and IT staff help as possible? From what I read it has grown past SOCKS and I figure someone has to have solved this problem before me.
Thanks for reading my long-winded question,
Ripred
If your software can make an SSL connection on port 443, then you are 99% of the way there.
Typically HTTP proxies are set up to proxy SSL-on-443 (for the purposes of HTTPS). You just need to teach your software to use the HTTP proxy. Check the HTTP RFCs for the full details, but the Cliffs Notes version is:
Connect to the HTTP proxy on the proxy port;
Send to the proxy:
.
CONNECT your.real.server:443 HTTP/1.1\r\n
Host: your.real.server:443\r\n
User-Agent: YourSoftware/1.234\r\n
\r\n
Then parse the proxy response, which will start with a HTTP status code, followed by HTTP headers, followed by a blank line. You'll then be talking with your destination (if the status code indicated success, anyway), and can start talking SSL.
In many corporate environments you'll have to authenticate with the proxy - this is almost always HTTP Basic Authentication, which is pretty easy - again, see the RFCs.