Click here to Skip to main content
15,176,561 members
Home / Discussions / ATL / WTL / STL


GeneralRe: sqlconfigdatasource fails on 64 bit from 64 application Pin
MrKBA11-Jan-13 0:14
MemberMrKBA11-Jan-13 0:14 
GeneralRe: sqlconfigdatasource fails on 64 bit from 64 application Pin
Richard MacCutchan11-Jan-13 0:32
mveRichard MacCutchan11-Jan-13 0:32 
QuestionProblem with embedded ATL component Pin
HungryCPPDev7-Jan-13 2:08
MemberHungryCPPDev7-Jan-13 2:08 
Questionbooks: activeX and com, Pin
bkelly131-Jan-13 10:58
Memberbkelly131-Jan-13 10:58 
AnswerRe: books: activeX and com, Pin
Jonathan Davies10-Jan-13 2:56
MemberJonathan Davies10-Jan-13 2:56 
QuestionWhile launching a winapp as ole server some time OnFIleNew() failed Pin
vermaashish_mca31-Dec-12 1:27
Membervermaashish_mca31-Dec-12 1:27 
QuestionTCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
bkelly1321-Dec-12 7:09
Memberbkelly1321-Dec-12 7:09 
AnswerRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
pasztorpisti22-Dec-12 10:51
Memberpasztorpisti22-Dec-12 10:51 
Networking is always tricky because you have to tweak the parameters of your networking code to get as "nearly optimal" results as you can. Regardless of the solution you choose you should definitely try to set the send and/or recv bufsize associated with your socket handle (setsockopt() call with SO_RCVBUF/SO_SNDBUF parameters). Set the buffer sizes for example to 1Megabyte and then halve it until your net performance starts degrading. Note that even if you use async sockets the os is still receiving and storing data in the background into the rcv buf of your socket and then you can read that out with a single call! Unfortunately if you use a socket implementation that doesn't allow you to have direct access to the size parameter of your send() / recv() calls then you can not tweak those! Whether async or blocking??? I think this shouldn't be the question. If done well then these should have about the same performance because blocking/async communications are really just 2 different ways to write/read the send and recv buffers of the socket object, the real networking is done by the operating system in the background by the network stack that works with the send/recv buffers of the socket. I prefer async because that is a superset of blocking sockets, you can not solve every problems with just blocking sockets. Servers with the highest performance are also using async because lots of async operations from different sources can be optimized much neatly by the OS anyway.

To be honest I have always written the async socket class for myself, mainly because of crossplatform development. I think writing a basic async socket code is no big deal but you will probably face some problems if you dont read the win32 api docs carefully. On windows you have several choices to write a single async socket - select, WSAWaitForMultipleEvents, iocp, overlapped, ... who knows). To handle a single async socket on its dedicated thread I have always used WSAWaitForMultipleEvents as it is quite easy to use with its companion functions (WSAEventSelect/WSAWaitForMultipleEvents/WSAEnumNetworkEvents). Why WSAWaitForMultipleEvents and not the crossplatform select??? Because with WSAWaitForMultipleEvents you can wait for the socket and also for a custom event of yours (created with WSACreateEvent) because sometimes you have to explicitly wake up the waiting - for example when your program quits or when you add some sendable data to your empty send buffer and your network thread waits. Doing the same wakeup with select() is always tricky and dirty.

Note that previously we were talking only about exchanging data between your application and the network stack (the socket buffers). There is a delay between the send or recv calls that you use to transfer data between the socket buffers and your application memory buffers. If this delay is big, for example because you do other work on your network thread and you don't have a dedicated network thread in your app then the delays will be bigger and you will have to compensate for that with bigger SO_SNDBUF and SO_RCVBUF values because the OS might run out of recvbuf space of the socket or might run out of sendable data while your network thread is doing something in your app. I highly recommend using dedicated threads that do just the transfer between your memory buffers and the socket buffers.

Another thing that can be a bottleneck is the data processing of your application - filling the application layer send buffer and reading the application layer recv buffer and doing some other stuff with the data (calculations, file io, ...). For example if your data processor thread doesn't read your memory buffer quickly enough then it might happen that the network thread that reads data from the socket buffer have to suspend transferring data from the socket recv buffer to your application level memory buffer because its full. Then if the OS/network stack fills up the recv buffer of the socket completely then you cant keep up with the network bandwith and it will affect performance. Lets assume that you are doing calculations with the received data and then you write it out to disk. If it can happen that some kind of data requires more processing than the average kind of data then you might want to compensate those "negative performance peeks" of your processor thread with a larger recv mem buffer in your application but you benefit from this only if the average processing speed of your application is bigger than what is required by the average incoming data. -> This shows quite well that you can tweak a networking application only if you know the exact specs (server hardware configuration, network config, ...). There is no single good solution. You will have to profile each part of your application independently (network recv/send speed, data processing, file io, ...) and then you will have to find out where to put buffers, maybe threads in between parts.
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
bkelly1327-Dec-12 7:16
Memberbkelly1327-Dec-12 7:16 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
pasztorpisti27-Dec-12 14:47
Memberpasztorpisti27-Dec-12 14:47 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
bkelly1328-Dec-12 4:08
Memberbkelly1328-Dec-12 4:08 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
pasztorpisti28-Dec-12 4:37
Memberpasztorpisti28-Dec-12 4:37 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
bkelly1327-Dec-12 9:22
Memberbkelly1327-Dec-12 9:22 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
pasztorpisti27-Dec-12 15:02
Memberpasztorpisti27-Dec-12 15:02 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
SoMad27-Dec-12 15:51
professionalSoMad27-Dec-12 15:51 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
bkelly1328-Dec-12 4:13
Memberbkelly1328-Dec-12 4:13 
GeneralRe: TCP blocking -vs- CAsyncSocket -vs- Win32 API Pin
pasztorpisti28-Dec-12 6:06
Memberpasztorpisti28-Dec-12 6:06 
Questioncalling virtual base class Pin
bkelly1314-Dec-12 8:36
Memberbkelly1314-Dec-12 8:36 
AnswerRe: calling virtual base class Pin
pasztorpisti18-Dec-12 23:39
Memberpasztorpisti18-Dec-12 23:39 
AnswerRe: calling virtual base class Pin
Albert Holguin19-Dec-12 8:22
professionalAlbert Holguin19-Dec-12 8:22 
GeneralThe reason for the question Pin
bkelly1319-Dec-12 16:51
Memberbkelly1319-Dec-12 16:51 
GeneralRe: The reason for the question Pin
Richard MacCutchan20-Dec-12 0:06
mveRichard MacCutchan20-Dec-12 0:06 
GeneralRe: The reason for the question Pin
bkelly1321-Dec-12 7:11
Memberbkelly1321-Dec-12 7:11 
Questioncannot add control variable to checkbox Pin
bkelly1314-Dec-12 4:07
Memberbkelly1314-Dec-12 4:07 
AnswerRe: cannot add control variable to checkbox Pin
Richard MacCutchan14-Dec-12 4:36
mveRichard MacCutchan14-Dec-12 4:36 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.