|
A good place to look at [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Member 716143 wrote: Need to read and write to a circuit board which gives out continuous output on the serial port.
Output is a very generic terminology to use when asking for serial port advice.
What are your requirements?
Are you sending data over serial or do you require granular control over individual data pins?
For transferring data over serial this MSDN article contains nearly everything you need to know:
Serial Communications in Win32[^]
If you need granular control over data pins this BeyondLogic article gives in-depth details:
Interfacing the Serial / RS232 Port[^]
Best Wishes,
-David Delaune
|
|
|
|
|
I hope client can send some secure data at connect time vs CSocket::Connect, so that server can read the data and knows it is my client connection, or server rejects the connection immediately.
Is it possible to send user data vs CSocket::Connect?
|
|
|
|
|
includeh10 wrote: Is it possible to send user data vs CSocket::Connect?
Don't think so - I think authentication (for that's what you want) has to be done separately post-connect.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
includeh10 wrote: I hope client can send some secure data at connect time vs CSocket::Connect
In order to send and receive data during a connect operation you will need to use WSAConnect() rather than CSocket::Connect(). Keep in mind this is protocol dependent and is not supported by the TCP/IP stack.
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
Note Connect data is supported only on ATM (RAWWAN) over a raw socket. TCP/IP in Windows does not support connect data.
it's my pleasure to make friend with you.
|
|
|
|
|
zhu_lin wrote: Connect data is supported only on ATM (RAWWAN) over a raw socket
Which would make it protocol dependent.
zhu_lin wrote: TCP/IP in Windows does not support connect data.
echo...echo...echo...
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
from the msdn about WSAConnect:
The lpCallerData parameter contains a pointer to any user data that is to be sent along with the connection request (called connect data). This is additional data, not in the normal network data stream, that is sent with network requests to establish a connection. This option is used by legacy protocols such as DECNet, OSI TP4, and others.
Note Connect data is not supported by the TCP/IP protocol in Windows. Connect data is supported only on ATM (RAWWAN) over a raw socket.
it's my pleasure to make friend with you.
|
|
|
|
|
Hello,
You cannot do such a thing. Any validation should be done after accepting the connection only.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
No, a TCP stream must connect before exchanging data.
|
|
|
|
|
My client/server program is almost completed, the server may accept thousands of clients in real use.
As test, I generated 20 clients with heavy conversations to server, all are fine.
But ..., I never use any thread for listing, receving and sending.
From CSocket idea, I do think thread is not neccessary, however, I have a little suspection about this.
If you have created real commercial client/server programs before, which used CSocket, I need your comments:
Do you think thread is a must (or good, better) for client/server (TCP/IP) CSocket program? if yes, why?
Thanks
modified on Wednesday, August 12, 2009 1:25 PM
|
|
|
|
|
IIRC, MFC CSocket spawns its own thread for handling the data and it is this thread that sends the window messages that trigger CSocket methods such as OnReceive. So in a sense, you are already using a thread.
In general, if it works the way you want it to... why change it? Then again, you only used 20 clients to stress test a system that may have thousands. You may still need a better stress test. Although that would be true whether you leave it alone or change to a more direct threaded approach.
Just my $0.02.
|
|
|
|
|
Usage of threads would largely depend on the data transfer and the number of simultaneous connections. If the data transfer and number of connections are high, then use the UI thread to accept connections and let a pool of background threads process the requests. If you're streaming something (like audio/video) to all clients, then dedicate a separate thread at the client side to handle this.
I would also like to mention that if you are planning to have a very high number of connections, then better drop MFC's socket classes and write it in Win32. MFC rather imposes a severe performance penalty (but is OK for the typical client/server stuff that's done - I'm talking about extreme cases, where performance is of high importance). I've experienced this from my work.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
1. normally, waiting needs a thread or process will be blocked, I think wmailory is correct: CSocket uses thread in Accept and Receive. in win32 socket, thread should be a must (no experience, just guess). If CSocket uses thread already, the user sub-thread should not be used again.
2. could you mention main drawbacks of CSocket? I may change it if neccessary. the server is very heavy: it will handle at least 100,000 clients (vs sub-servers).
|
|
|
|
|
1. Yes, CSocket does use a thread internally to provide us with the 'blocking' nature.
2. The MFC socket classes work perfectly, but they have a tendency to choke early (as in comparison with plain Win32 socket programming). The framework brings in this additional penalty. I see that MFC may not suit your needs best. When I wanted a high performance server, I had to go with Win32 for the same reason I mentioned. I was only aiming at 1000 (to 3000 clients in peak time). I ended up writing both (MFC and a non MFC program). You may have to do some stress testing and find out where it breaks. 100,000 looks like a huge number to me; good luck with that.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
CSocket does not create a separate thread. It does however create a window which is used as an event sink for asynchronous operations. When an asynchronous operation such as Send is invoked the CSocket object will enter the message pump until the operation is completed. Once the operation completes the event is placed in a queue and then dispatched to the appropriate method (OnSend, OnAccept, etc).
Overall CSocket is more suited for general client connectivity rather than servers - especially high load servers. You would be better off calling the Winsock API directly and using IO completion ports.
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
Bacon Ultimate Cheeseburger wrote: CSocket does not create a separate thread.
Are you sure? I was pretty sure it did.
OK, I just ran the debugger on one of my programs that uses a CAsyncSocket object. The debugger shows a thread named _SockAsyncThread@4 in the list of threads. Since CSocket is derived from CAsyncSocket, I assumed it would also create a thread.
|
|
|
|
|
wmallory wrote: Are you sure? I was pretty sure it did.
SockAsyncThread is a thread entry point used by service providers for handling asynchronous socket operations.
I am a lean mean ground beef machine!!!
|
|
|
|
|
Ah... that's quite a bit different than what I was assuming. Thanks for the info.
|
|
|
|
|
includeh10 wrote: From CSocket idea, I do think thread is not neccessary, however, I have a little suspection about this.
CSocket is a wrapper around an event based networking model. If you want to get better performance have a look at CAsyncSocket or IO completition ports. Further information in the Winsock programmer's FAQ[^]. Hope it helps.
/M
|
|
|
|
|
Hi all,
I'm in the process of writing my own Matrix Library, and have been using the standard way to copy things around, i.e. if i have a pointer to a bunch of doubles, say
T * my_doubles = new T[64];
representing an 8 by 8 array, then if i want a copy constructor of a class to duplicate this then i just issue the following code in the copy constructor:
for(unsigned int count = 0; count < 64; count++)
new_doubles[count] = my_doubles[count];
however, i have been reading around on the net that there are faster ways to copy memory, mainly using memcpy. i have also learned that some people are against the use of this because the compiler optimizes code such as that above to be the most efficient.
so what's it to be?... regarding SPEED, is it really best to let the compiler optimize, or use memcpy, or some other method?... and if so what are these methods?
Many thanks,
Paul
|
|
|
|
|
Why don't you do some tests?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hmm... Fastest way to copy memory.
I was thinking of a memory copying API tied to a Hayabusa.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Indeed: My pen drive is quite fast memory when I drive the GSR..
BTW: nice THHB action, today...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
(