I am writing some code for a client and server using c++.
I am using boost serialize to serialize an object on the client side and then send it to a server.
The server then unserializes the stream and recreates the object.
The server then calls the run function of the object.
The server then serializes the object and sends it back to the client.
The reason I am doing the above is for instance the client needs to know what files are in the /home/dataIncoming folder on the server.
This is just one simple example
My question is that it seems that for the objects that are serialized I need the same code on the server AND the client. Or how would the server know how to unserialize the object sent.
Thus if I change the server code i need to make sure I also get the code over to the client program.
How do programmers easily solve this problem of duplicate code on the client and the server?
Or is there some way I could serialize so this duplicate code did not need to exist on the client and the server?
or do i simply send a protocol stream over to the server and have the server read in that protocol stream to reconstruct commands to be run and info to be sent back.
It seems easiest to just construct an object on the client side, have it run on the server, then sent it back to the client with results.
Thanks for all your ideas!
For generic client server operations:
You compile your code into a library, and use the library on both the client and server.
Your client and server both need to understand the data format. There is no way around this.
You could have a more abstract layer that allows the client to submit the format of new data types, but this abstract layer itself would need to be a data format understood by both the client and server.
It's unclear to me how your example differs (it at all) from the generic case.
The client and the server have to share data (and the data format), but not the code.
It sounds like your object encapsulates three things:
The data
Some client code
Some server code
A lot of object oriented programming encourages putting data and the code that operates on it into the same object, but that's not always the best solution. Why not separate those things out?
Put your data into a data object and serialize that. The server would have something that operated on that data (presumably some object, not necessarily though) and the client would have something that operated on that data. So, I think you just need to reconsider how your programs are structured.
The architecture you describe also has another downside. If you want to modify the behavior of the server, you have to also update the client. If these concerns were separate, this wouldn't be a problem. The only reason you would have to update both the client and the server is if the data format changes.
Usually the Encoding and Decoding is taken care by the serialization library that you use. (google prorpbuf, nano-pb, boost etc)
However Since the encoded from and decoded to classes/structures would be essentially be the same.
So essentially we need the same information on both ends (server and the client)
A good idea is to create a dll or an .so for this functional module which when changed can be reflected on both the server and the client, without recompilation.
Related
I am trying to implement secure communication between a server and client in c++. The limitation is that both the client and server must run on windows and have to be in c++. This is for a research project I am working on at my university.
So far I have found that SChannel is the best option, but the documentation is extremely confusing and I can not find any guides/tutorials on how to use it. I have already looked at this link https://learn.microsoft.com/en-us/windows/desktop/secauthn/creating-a-secure-connection-using-schannel but still do not understand how to get it working. Could someone guide me through this if this is the best way?
I also looked into use SSLStream using the CLR to have .net run inside of a c++ application. However I can not use this because the client application is threaded and threads can't be used with CLR.
I already have a dummy client and server set up with communication between the two, I am just trying to secure and encrypt that communication.
Any help is greatly appreciated!
Whichever SSL library you choose to use there are a few things you need to know as a beginner in this field:
The server and client implementations will end up looking quite different in places.
Your server is absolutely going to need a certificate with a private key. During development you clearly don't want to get one from Verisign or something so you need to create a self-signed certificate. You can do this with openssl or other tools.
The certificate consists of a private part and a public part. The public part needs to go to the client, and will be used to validate the connection. When you are using something like SChannel the certificates (private and public) will need to be installed in the certificate stores of the server and client respectively.
SChannel does not send or receive data for you. So the core of your implementation is going to be: when the network has data: read ciphertext from socket and write to SChannel. Read clear text from SChannel (if any) and pass to application. When the application has data to send, get clear text from Application and pass to SChannel. Get the resulting ciphertext buffers from SChannel and write to the socket.
buffers from the internet may be partial, and negotiations and re-negotiations means there's no 1:1 mapping of passing data into SChannel and getting data out.
You therefore can't get away with a naive implementation that calls SChannel once to pass data in, and once again to get un/encrypted data. There will potentially be nothing available, or a whole lot of packets to send between the client and the server, before you'll get any application bytes. i.e. You will need some kind of state machine to keeptrack of this.
Obviously, don't write both the client and server at the same time: Start with your client against an https server.
That's the general outline of the process - the things that confused me when I first encountered SSL and why none of the samples were nearly as simple as I had hoped them to be.
I am trying to write a simple client-server application where a client can send or broadcast a message to one or all clients in the network. The server stores all IP addresses that are connected to it, and broadcasts a new IP if a new client connects itself.
I'm not quite sure how to implement the sending of a single message to another client. Would I just have to send a TCP message to the server and put the desired recipient as data in the TCP layer which is then extracted by the server so it knows where to send it?
I also want to add encryption to the messages which would then no longer allow the server to read the data, so I'm not sure how to solve that!?
I am using c++ and Qt5 for the implementation
I'm not quite sure how to implement the sending of a single message to
another client. Would I just have to send a TCP message to the server
and put the desired recipient as data in the TCP layer which is then
extracted by the server so it knows where to send it?
In an ideal world, the clients could talk to each other directly, since they could find out the IP addresses of the other clients from the server (either via its broadcast or by requesting a list of IP addresses from the server). If all of your clients are running on the same LAN, that can work well.
Assuming you want your system to run on the general Internet, however, that won't work so well, since many/most clients will be behind various firewalls and so they won't accept incoming TCP connections. (There are some ways around that, but they require a very advanced understanding of how TCP works, and even then they only work in certain situations, so I don't recommend attempting them in a first project)
Therefore, for a reliable client->client messaging mechanism, your best bet is indeed to have the sending client send the message to the server, along with some short header that tells the server which other client(s) the message ought to be forwarded to. My own client/server messaging system works along these lines, and I've found it to work well.
I also want to add encryption to the messages which would then no
longer allow the server to read the data, so I'm not sure how to solve
that!?
Don't worry about adding encryption until you've got the basic non-encrypted functionality working first, since encryption will make things much more difficult to debug. That said, it's perfectly possible to pass encrypted/opaque data to the server, as long as the aforementioned header data (which tells the server where to forward the message to) is not encrypted (since the server will need to be able to read the header to know what to do with the encrypted data). The trickier part will be when the receiving client gets the forwarded data from the server -- how will the receiving client know how to decrypt it? You'll need some external mechanism for clients to share keys (either symmetric keys or public/private keypairs), since if you sent the encryption keys themselves through the server, there wouldn't be much point in encrypting anything (since the server could retain a copy of any keys it forwarded, and use them to decrypt, if it wanted to)
I am working on an application that, among other applications, allows users to send emails. It works by writing everything onto an SQL server, so you can have multiple instances of an application.
The email sending currently works with an "Outbox" table on the SQL server, to which application instances directly write the data with SQL statements. I have, however, hit an issue, that a requirement for attachments on the emails has arisen.
My thinking is that if I can send the attached files to a directory on which the SQL server resides (possibly the TEMP directory?), and then store the path to that file (or a UUID, if the file is constant) in the table. The issue is I have no idea particularly where to start with sending the file, as I am still vaguely new to C++.
One term I have come across is sending it with sockets, but am struggling with where to start with it and do not know if it is indeed the best option. Could anyone provide some advice on this matter?
Thanks in advance.
If I correctly understand the way it works (applications save the emails to SQL then another application takes them out and sends them) you have two choices:
Save the attachment as binary in the SQL and have the mailer application do the rest.
Use sockets to transfer the file to the SQL server and save the path to it just as you said.
I'd say option 1 would be the best option if I understood correctly the way its currently working. And as for option 2, there are probably other ways to transfer the file but sockets would be the easily cross-platform option.
Its not hard to get started with sockets, there are a lot of examples all over the internet.
winsock
more winsock
sys/socket.h
more sys/socket.h
I have some framework doing specific task in C++ and a django-based web app. The idea is to launch this framework, receive some data from it, send some data or request and check it's status in some period.
I'm looking for the best way of communication. Both apps run on the same server. I was wondering if a json server in C++ is a good idea. Django would send a request to this server, and server would parse it, and delegate a worker thread to complete the task. Almost all data that need to be send is string-like. Other data will be stored in database so there is no problem with that.
Is JSON a good idea? Maybe you know some better mechanism for local communication between C++ and django?
If your requirement is guaranteed to always have the C++ application on the same machine as the Django web application, include the C++ code by converting it into a shared library and wrapping python around it. Just like this Calling C/C++ from python?
JSON and other serializations make sense if you are going to do remote calls and the code needs to communicate across machines.
JSON seems like a fair enough choice for data serialization - it's good at handling strings and there's existing libraries for encoding/decoding JSON in both python & C++.
However, I think your bigger problem is likely to be the transport protocol that you use for transferring JSON between your client and server. Here's some options:
You could build an HTTP server into your C++ application (which I think might be what you mean by "JSON server" in your question), which would work fine, though might be a bit of a pain to implement unless you get a hold of a library to handle the hard work for you.
Another option might be to use the 0MQ library to send JSON (or otherwise) messages between your client and server. I think this would probably be a lot easier than implementing a full HTTP server, and 0MQ has some interprocess communication code that would likely be a lot faster than sending things over the network.
A third option would just be to run your C++ as a standalone application and pass the data in to it via stdin or command line parameters. This is probably the simplest way to do things, though may not be the most flexble. If you were to go this way, you might be better off just building a Python/C++ binding as suggested by ablm.
Alternatively you could attempt to build some sort of job queue based on redis or something other database system. The idea being that your django application puts some JSON describing the job into the job queue, and then the C++ application could periodically poll the queue, and use a seperate redis entry to pass the results back to the client. This could have the advantage that you could reasonably easily have several "workers" reading from the job queue with minimal effort.
There's almost definitely some other ways to go about it, but those are the ones that immediately spring to mind.
this is my first question, so sorry if the form is wrong!
I'm trying to make thrift server (python) and client (c++).
However I need to exchange messages in both direction. Client should register (call server's function and wait), and server should listen on same port for N (N-> 100k) incoming connections (clients). After some conditions are satisfied, server needs to call functions on each client and collect results and interpret them.
I'm little confused, and first questions is "can this be done in Thrift"?
Second question is related to mechanism that will allow me bidirectional communication. I guess that I will need two services. One with client's functions other with server's.
But I'm confused with calling code. I understand one way communication (calling functions from server), but with calling functions from client side I have a problem.
Any suggestions???
Thanks!
Consider using boost::asio for your client side, though depending on your level of C++, the code may seem too dense.
If you're looking for a simple example, take a look at:
http://www.linuxhowtos.org/C_C++/socket.htm
It contains both server-side and client-side code. Both sides create a socket and two-way communication is achieved by each side posting data to the socket. The server side is generally multi-threaded (with one thread per connection). The client side can be implemented as a single-threaded loop that alternates between querying the socket for any incoming information, performing computations, and posting results back to the socket.
Since, you say you are having problem with calling functions from client side, here is a sample Thrift code with Java server and C++ client, where the client calls a function in server. http://fundoonick.blogspot.com/2010/06/sample-thrift-program-for-server-in.html
Hope this helps :)