ATL / WTL / STL

8-Nov-14 16:31

A transition from VS2008 to VS2012 has prompted some re-factoring.

I am the only one in my small group that writes in C++ or with OOP. My “plus plus” skills are self-taught with no opportunity for peer-to-peer discussions. Please forgive me for asking dumb question and give some basic guidance here. I do have rather significant skills in number crunching and handling high data rate non-OOP programming.

I am developing my TCP/API skills with a Server side all and a client side app. These will use the windows TCP/API with non-blocking and overlapped operations. To that end I envision the two classes:

C_TCP_API_Server
C_TCP_API_Client

But there is much functionality that is common to both classes, such as creating the sockets and setting their characteristics. I envision something like:

C_TCP_API_Core

This is to contain most or all of the low level API calls and all the error handling that goes with that.
That changes the first two classes to be:

Class C_TCP_API_Server :  public C_TCP_API_Core
Class C_TCP_API_Client :  public C_TCP_API_Core

This is the first time I have considered using inheritance. Code efficiency overrides simplicity.
Is this the right way to go?
Should the core class be abstract? Or would that be getting a bit advanced for me.

BTW: I Put the API in the class names to indicate that this code goes as close to the Windows API and the lowest level code I can get. I want the minimum overhead between the code I wrote and the OS (Operating System). It will be handling high and continuous data rates.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Garth J Lancaster8-Nov-14 16:56

Garth J Lancaster

8-Nov-14 16:56

my 0.02c worth

if you're comfortable with inheritance, abstraction etc - or want to learn and get comfortable, why not ?

otoh, Ive seen plenty of implementations that are basically C_TCP_API, that have both a client and a server 'listen' method - since they share 90% common code, I see no issue there, either

There will be the purists who will argue left right and center about maintainability, separation of concern, yada yada, fine - Im a pragmatist a) make it work, b) make it pretty and maintainable

bkelly139-Nov-14 2:15

9-Nov-14 2:15

client && server versus client || server, good point. I hadn't thought on that much. I tend to go the separate route for simplicity but will consider more.
Thanks for taking the time to reply.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Garth J Lancaster8-Nov-14 17:06

Garth J Lancaster

8-Nov-14 17:06

btw, saw your issue with the IPAddressControl below

the difference between the IPAddressControl and the NetAddressCOntrol is, that the IPAddressControl will only handle IPV4 tcp/ip addresses, while the more complicated NetAddressControl will handle IPV4, IPV6 and DNS type addresses, BUT NEEDS TO BE TOLD which one its dealing with, with its 'SetAllowType' Method

Other than that, they should work almost the same - http://msdn.microsoft.com/en-us/library/bb399237.aspx[^]

'g'

bkelly139-Nov-14 2:19

9-Nov-14 2:19

Re IP versus NET, I had not recognized that difference, and it immediately explains much. I work in the arena of telemetry systems who are probably completely exclusive groups, meaning their systems are closed off from the public world. I will stick with the IP4 through the completion of this project, at least the first version, then see about re-visiting.

Thanks for recognizing that and taking the time to reply.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

modified 9-Nov-14 12:10pm.

Albert Holguin10-Nov-14 4:58

Albert Holguin

10-Nov-14 4:58

bkelly13 wrote:
This is the first time I have considered using inheritance. Code efficiency overrides simplicity.

Is this the right way to go?

Should the core class be abstract? Or would that be getting a bit advanced for me.

Sure why not? ...if there is enough overlapping code that needs to be written, it makes sense to use a common base class, after all that's the point of inheritance.

If you want to see how somebody else has done something similar, check out the Practical Sockets[^] library. As a matter of fact, that library may already be doing what you're doing...

bkelly1310-Nov-14 12:40

10-Nov-14 12:40

Thanks for the comment and the link.

I am doing this as self guided education and for use at work. The main app will start a function as a thread and that will instantiate the TCP class and start a method in the TCP/IP class to conduct all the I/O. That method will run until completion. The entire app is a high data rate telemetry system.

I have divided the send and receive into two separate paths, one to send and one to receive. Each path is a strict producer and consumer link. That tremendously reduces the complexity in communications between the main and the TCP thread. Its almost trivial.

At the lowest level, the TCP class starts a completion thread for the send side and soon will start another completion thread for the receive side.

All the TCP code is driven by events, no polling.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Multiple threads explained

Albert Holguin10-Nov-14 16:47

Albert Holguin

10-Nov-14 16:47

bkelly13 wrote:
At the lowest level, the TCP class starts a completion thread for the send side and soon will start another completion thread for the receive side.

I hope you're not literally starting a thread... that's actually a VERY slow process. If you have worker threads that do the same thing over and over again, it's best to start the threads once and leave them around until they're no longer required. You can use the thread pool concept if you need several worker threads instead of just one or two per IO.

Also, depending on the bandwidth, TCP/IP isn't the fastest thing in the world. I doubt telemetry can produce bandwidths high enough to cause a problem but if you start seeing backups, keep in mind that you're paying for the overhead involved in TCP/IP.

bkelly1311-Nov-14 6:30

Re: Multiple threads explained

11-Nov-14 6:30

Yes, I mean start a thread. Clarification will be helpful. On start up the main app will create/instantiate the class that handles all the TCP/IP communications. That is separate thread from main. That class will create a separate thread just for the send completion events and another for the receive completion events. After all that is done, then the system is ready to process data. The threads all run until main app is shut down. There is no dynamic thread creation and destruction while moving data. This app uses overlapped I/O and completion events.

Why create two more threads? Because I discovered that a thread that did nothing but handle the send completion events would be rather simple. The breakout of that code from the TCP/IP class into the thread did much to simplify the TCP class that communicates with main and controls the details of the TCP/IP link. Then it was just a small step to do the same with the receive side.

TCP is the only method we have to transfer data between computers. Our display system only accepts data via TCP/IP. Our mission system is contained within a single room and the Ethernet bandwidth is 1Gbps. And for this particular link there is a dedicated port on the send and receive computers that carries nothing but the telemetry traffic.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Albert Holguin11-Nov-14 7:01

Albert Holguin

11-Nov-14 7:01

bkelly13 wrote:
TCP is the only method we have to transfer data between computers. --------------------------. Our mission system is contained within a single room and the Ethernet bandwidth is 1Gbps.

Those statements are contradictory... the presence of Ethernet does not imply TCP/IP. There are different protocols that can be used over Ethernet (even raw Ethernet). Some, like TCP/IP, are built for error checking... some are built for speed.

bkelly13 wrote:
Our display system only accepts data via TCP/IP.

Typically a GUI display and any other processing are completely independent of one another.

Re: Multiple threads explained

bkelly1311-Nov-14 9:58

11-Nov-14 9:58

I stand corrected. The display system is provided by Symvionics and it only accepts data via a TCP/IP connection.

Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com

Time of reading text file

pasztorpisti10-Jan-15 11:06

pasztorpisti

10-Jan-15 11:06

In my client and server classes never inherited a common base class. They just used some common components/classes like a socket class, whatever. Often its cleaner and more correct to use composition than inheritance. Over-generalization is usually a bad thing that should be resolved later. I refer with this to the "Core" base class here. I guess "Core" here means a lot of things and you create an "is a" relationship with inheritance between Server and Core and between Client and Core, so basically your server "is a" set of a lot of things that means chaos. In case of simple programs its OK to have not so nice design but if you want to do it correctly then try to isolate components and features that can be correctly named and encapsulated into a class (like Socket). In my networked programs other components that often come to the scene are "Connection", "Channel", "Server-SideClientHandler" or whatever. So instead of inheriting from a common base class I think here its usually nicer to isolate common things into classes and just using those classes from both the server and the client. If I inherited from a common base class in this case than it would probably be a CApplication class or something similar in case of using a framework...

Another little note related to naming convention (although this is a matter of taste): When I have complex names like C_TCP_API_Server I usually remove parts of the name and use them as namespaces. For example in case of C_TCP_API_Server I would probably use a C_Server class that is inside a TCP_API namespace. This is however just style, its up to you how to name and organize things your code. I've already worked on codebases where the usage of namespaces was forbidden as part of the coding conventions.

/off
Fun fact: In my experience the most dangerous classes in object oriented code often have these names: Something-"Manager", Something-"System", Something-"Handler", Something-"Core", ... Big Grin | :-D

/on

econy7-Nov-14 4:24

7-Nov-14 4:24

Hi, I wrote a program in Windows CE platform, CPU is ARM 427MHZ.
when program read a text file(size about 700KB,1000 lines) in Flash memory, it needs about 25 seconds to load the file.

is there a means to decrease the reading time?

C++

file.Open(fileName,CFile::typeBinary | CFile::modeRead);
while ( UNReadString(&file,strLine) ) {
		//strLine.TrimLeft(); TrimRight(); N
		strLine.Trim();
		
		strNum  = strLine.Tokenize(TEXT("\t"),tokenPos);	
		strEng = strLine.Tokenize(TEXT("\t"),tokenPos);	//Get English text
		strCh  = strLine.Tokenize(TEXT("\t"),tokenPos);	
		strRus = strLine.Tokenize(TEXT("\t"),tokenPos);
                
        handleStr();
        tokenPos = 0;
}

BOOL UNReadString(CFile *iFile, CString &strReturn)
{
	TCHAR tc;
	CString strBuff = _T("");
	strReturn = _T("");

	while( ( sizeof(TCHAR) ) == ( iFile->Read(&tc, sizeof(TCHAR))) ) //EOF reached?
	{
		strBuff = tc;

		if(_T("\n") != strBuff) {
			strReturn += strBuff;
		}
		else {
			return TRUE;	//Reached "\n", 1 line added to strReturn
		}
	}
	return FALSE;
}

modified 11-Nov-14 12:55pm.

Richard MacCutchan8-Nov-14 21:33

8-Nov-14 21:33

econy wrote:
file.Open(fileName,CFile::typeBinary | CFile::modeRead);

Why do you open a textfile in binary mode? You will also find that your use of Trim and Tokenize on each line will add considerably to the time.

econy11-Nov-14 2:06

11-Nov-14 2:06

Since there are east asian words in the file, and I try to comment tokenize block, no update

Richard MacCutchan11-Nov-14 5:42

11-Nov-14 5:42

What does UNReadString do, I cannot find a definition for it?

econy11-Nov-14 6:56

11-Nov-14 6:56

had added code for:

UNReadString(CFile *iFile, CString &strReturn)

Richard MacCutchan11-Nov-14 7:05

11-Nov-14 7:05

Sorry, I was not clear; I meant that I could not find a definition for that function in MSDN, so I do not know what it does. Is this a standard part of WindowsCE and if so where is the documentation for it?

econy11-Nov-14 7:17

11-Nov-14 7:17

It is not a Wince or Windows function. I wrote it myself.

Richard MacCutchan11-Nov-14 7:25

11-Nov-14 7:25

Then that may well be the place where all your time is being used up.