Click here to Skip to main content
15,881,089 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
C++ and Windows Socket

I have a one to one Server Client app where the Server sends approximately 20,000 signals and the Client Independently sends 2000 different signals the other way. I am using asynchronous communication with one shared Port address. If I start sending the Client signals to the Server then the Server updates its copy of the signals correctly, but any signals it sends to the Client are slow at updating the Client copy of the sent signals. If I start sending the Server signals to the Client then the Client updates its copy of the signals correctly, but any signals it sends to the Server are not tracked efficiently.

It would be ideal for the Client to send its data on a different Port to that which it is recieving data. However, I dont know if that is possible. I might be able to set the Client up as a Server itself to just send data on a different Port to the true Server. The answer may lie in multi-threading, however the Client machine has multithreading disabled! I have read a few bits on completion ports but that may rely on multi-threading as well.

Is there an easy way of setting up efficient asynchronous data flows (dual port options would seem best if I only need to add another Port address to my current code), or will my other solutions be required, or possible?
Posted
Comments
Sergey Alexandrovich Kryukov 18-Nov-12 11:21am    
How a machine can have multithreading disabled? What kind of a machine is that?
--SA
psychokeith 18-Nov-12 13:21pm    
Sorry but the machine runs old Software that we were told will not work properly with multithreading enabled - seems rather stange to me as well!
Sergey Alexandrovich Kryukov 28-Nov-12 19:53pm    
Hard case, sounds like... :-)
--SA
[no name] 20-Nov-12 22:22pm    
You have not stated what the machine, operating system and development environment are.
As SA has stated "disabled multithreading" is whacky. Many of your services would not run.
Most Client server apps are all about multithreading.
You need to clarify what you are talking about.
psychokeith 22-Nov-12 18:11pm    
The "Client" target is a Windows 2000 Server with Single Core - Hyperthreading disabled - and the other machine is a fully threaded multi-cored XP machine. However I am developing the app on two XP machines with hperthreading enabled - and I still have the problem that if the client is sending data the Server listens and picks up the changes, but does not send its own data back down the socket for the client to update in a timely fashion

The Port I am referring to is from
Client::Client( const char* host, const char* port, AddStringListener* pDebugWin )
etc
{
m_address = INETAddr( host, port );
}
where port is set at 3040 or there abouts

I hope this clarifies a few things. The actual code contains alot of specific code, so my question is based on generalities, so that I can look at a few solutions. I am currently chopping up the Data so the client signals work as they do now with the Server listening on say 3040, and the old Server signals being seperated out so the Client machine becomes a Listening Server Process and the Server becomes its client sending on say 3041 with the "client" listening as a Server on that port. This probably could get round the "multithreading" as they would then be two distinct applications. I dont know if this will work but it would seem a logical way of improving throughput! However. I am just open to suggestions at present! It might indeed be that the protoclos are not set up correctly, or I might need a stream in one direction and a UDP connection in the other direction. At the moment all data is queued and streamed. Again the bugs may be in the streaming, but it works extemely well in one direction!

The easy answer to your question would probably be someting like ØMQ \zeromq\[^]

You could also look at OpenDDS[^] as it sounds like you are working on something similar.

Best regards
Espen Harlinn
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 28-Nov-12 19:52pm    
Looks interesting! My 5.
--SA
Espen Harlinn 29-Nov-12 3:44am    
Thank you, Sergey :-D
Wendelius 12-Dec-12 0:22am    
Looks like a really good link. I have to dig it more thoroughly at some point.
Espen Harlinn 12-Dec-12 9:38am    
Thank you, Mika :-D
It sounds to me like the problem may be tied to the protocol that the sockets are using to communicate to one another.

Have you experimented with the WSAEnumProtocols function declared in Winsock2.h from the library Ws2_32.lib? Perhaps you just need to create a connection using the correct protocol for your legacy system.
 
Share this answer
 
First an observation - perhaps you are using slightly wrong terminology.

Your client/server connection is using one (probably TCP or UDP) connection (not "port", there are actually 2 ports involved, the source port and the destination port in any connection)

Subsequently, both client and server send data into the connection, asynchronously. (I am assuming your term "signal" really means "a chunk of data").

It is possible to execute a client in a single thread, in fact it is commonly the case that both receive and transmit parts are a part of the same thread. Therefore, as unusual as it sounds, you can run client code without multithreading.

(On the server, of course, you could not do this because each client connection is handled in a separate thread)

Assuming that so far I understand your situation correctly, then you must have a call to "receive" (or "recv") somewhere that returns, if no data is received, in a predefined time. (I don't know if you are using raw sockets or some wrapper on the top - so I am guessing here a bit. Also, I don't know if your sockets are set as blocking or not). If there is no physical data arriving or waiting in the buffer after a call to "recv", then your thread may be blocked, and with no multithreading, the client is performing busy waiting. Clearly, during this time you cannot send, or for that matter, do anything at all. This is probably why you are observing performance issues.

If you are using sockets, you can use "select" function to check for the status of the socket before calling "recv" to get the actual data, that would avoid blocking unnecessarily.

To sum it up, I think you have to have a really good look at receive section of client code to avoid any situation where it may block too long due to no data being available.
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900