What do threads or multiple processes have to do with the format in which you want to transfer data to the client?

The current vogue is to use JSON as a transport format.

I would also think about using XML together with an XSD, if the client is not under your control. Having an XSD makes communication between you and the other developer(s) much easier, as changes to the protocol will be documented through the XSD.

The current vogue is to use JSON as a transport format.

I second the use of JSON for transmitting data from one program to another. Because parsing JSON is generally quite easy and an "Array of Hashes" will become an "Array of Hashes" anywhere (or their language-specific equivalent) you can depend on a certain level of uniformity.

Also, since JSON is human-readable it is fairly easy to debug if you can get a dump of the JSON that is being transferred and parsed.

I would also think about using XML together with an XSD, if the client is not under your control. Having an XSD makes communication between you and the other developer(s) much easier, as changes to the protocol will be documented through the XSD.

Yes - XML + XSD (or even DTD) are more explicit and granular, and can serve for validation later on. If you prefer to stick with JSON all the way, you could use the emergent JSON Schema standard with JSON::Schema in your Perl and something else on the other end.

How can I transmit the complex data to client？

Ok. I would take that to mean that that you have implemented a server using TCP/IP. You have used Perl as an implementation language at the server end. That is fine.

The server gets a "key" and then replies back with a "value".

I have no idea of what the server should send based upon what the client sent - that's a server spec.

The client requests (sends a question) and expects complex data from the server (gets an answer). The client is expected to be able to understand the response from the server to its question.

Or should I use multi process or threads? Whoa! A client server is already at least multi-process or multi-thread.

Sounds like you not have a working TCP/IP server.
Explain more what you are trying to do and I'm sure you will get help.

A client server is already at least multi-process or multi-thread.

Only in the sense that both server and client are (likely) different processes. Neither server nor client needs to be multi-process or multi-threaded.

Ok, a select based server would not be either multi-threaded or multi-process. A select server is the least commonly implemented server model and is normally used for special high-performance response-time applications.

So what?

I doubt the OP has implemented a select server model.
A fork-based server is much easier to implement.

I think the OP should show a simple set of client <-> server code.
I am very sure that Monks will help iron out the details if the OP gets "close to the goal".

I don't know how that would help you with serializing your data, but the module Net::EasyTCP helps you setup socket connections, and it transparently handles serializing your data structures for you.

From an example in it's perldoc:

# Send and receive complex objects/strings/arrays/hashes by reference
  #
%hash = ("to be or" => "not to be" , "just another" => "perl hacker");
 $client->send(\%hash) || die "ERROR SENDING: $@\n";
 $reply = $client->receive() || die "ERROR RECEIVING: $@\n";
  foreach (keys %{$reply}) {
    print "Received key: $_ = $reply->{$_}\n";
    }
[download]

How can I transmit the complex data to client

All data that flows between the client and the server is a stream of bits. TCP/IP essentially guarantees that the bits that I send to you get received just like I sent them. That is true in either direction (server<->client, client<->server) once the connection is established.

Any data that is sent between the client and the server is done as per an agreed to protocol. The protocol typically assumes that not a single "bit"--NOTHING will be lost in this end to end transmission. This is part of the TCP/IP guarantee. Basically, you will get the text message verbatim as I sent it.

Just to be sure... “it makes no difference at all whether you have multiple processes or threads.”   Your requirement is ... to send complex (structured...) data to a client.

The very page that you are looking at right now is, of course, an example of “structured data” (a web page) that has been sent from a server (perlmonks) to a client (you).   The mutually agreed-upon format that was used is HTML.   Any “mutually agreed-upon format” could be used.   XML is the one that was designed by a committee.   JSON is the equally-functional (in many but not all cases) “lightweight” format that was not.   YAML is a third alternative that just happens to be my personal favorite.   Each of these has been designed to be easy to transmit on an HTTP circuit, and to be reasonably “human readable,” a very important practical consideration since we humans are going to be the ones who are called-upon to debug the thing.   (Hair follicles are precious.)

As you can surmise, it really does not matter so much which format you “mutually agree upon,” so long as the choice works well for everyone.