|
It totally depends on the problem you're trying to solve. If you're doing a web server and a web browser, then yes, a string over tcp would be ideal. Or are you copying file data? Is it really small atomic items - 4 bytes? The maybe a windows message. Or COM might be your best option.
Are these items going to be on the same system, or a true client/server?
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications. It's the new math! 421 == 156 !
|
|
|
|
|
T.Wilson wrote:
It totally depends on the problem you're trying to solve.
Well, I'm developing my own chatt server in order to learn socket programming "full out".
But I don't know how to create a good communication protocol and if it's going to be plain text or binary communication.
The first version of my chat will only have functionality for sending plain messages. Then when I know how to make that thing run good I will implement functionality for sending files also.
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
Rickard Andersson wrote:
I don't really know how to communicate between my server and client. Am I going to use a plain string and parse it?
I prefer plaintext TCP/IP communication vs binary communication, when possible.
A good example of a mixture is the Gnutella protocol: Handshake and file transfar is done in a HTTP alike plaintext protocol. while all other stuff (search requests and answers) are binary... possibly to save bandwith. Generally speaking, text protocols are flexible, easy to debug and good to understand. Binary protocols are better suited when performance matters (you know optimation is your worst enemy).
IRC is an example for a line based plaintext protocol, ICQ is an example for using binary packages. Oh, and another possibility that is available: using XML (and a library that parse data for you).
If you speak about a chat, perhaps imitate IRC protocol and use line based plaintext...
|
|
|
|
|
I've seen an IRC server that uses binary to communicate. But when you say it, I think plaintext communicating is the best.
PS. I knew you were going to answer me Moak!
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
Hi,
I'm developing server application (FTP server). It works very well and it is very stable under all platforms (win9x/2k/nt/xp). But now I have a problem. We have new LAN (100mb), very fast (file transfer from/to server about 5000 kB/s).
Here is the problem:
Under W9x, when I start uploading/downloading big file (at least 30 MB), transfer starts and everything seems to be ok. But, when I want to list directory in client (eg Total Commander), server gives no response and the machine where the server is running is totally frozen up. With one exception - file transfer that I've started before, is going on well...When I kill the connection from client, server is ok again (as well as the whole OS).
Some bug, I said. I tried to trace the error, so I put breakpoints to my socket OnReceive function. But NO DATA arrive to my socket, at least this function is never executed...I must note that this problem occurs only on this new LAN, when we had slower (10 mbps), it was ok...So where to search for the error ? I think that the bug must somewhere in CSocket/CAsyncSocket...
Thanks for anything...
Standa.
|
|
|
|
|
MFC Sockets are worthless for anything I (and lots of other people) would consder "real use". The problem is that they are still based on the Windows 3.1 sockets design, in that they need to have access to a message handler and etc.
What you're experiancing is probably message stavaration between the socket handlers and the windows handlers - you've got one socket loading down the handler, and none of the other ones can efecitivly get into it. For light use, MFC sockets can work on - for example, look at the Microsoft MSDN exampe "Chatsvr" which is a trivial messaging app using CSockets.
For more robust sockets, I would look into some of the other things here on CodeProject, in the Networking code section. You should also consider using threads to handle socket actions, so that one socket will not load down the system. This is the method I've used in a high-end 1000+ client server - one thread for each client SOCKET handle (no MFC in it).
WarFTP is open sourced I think, and is a Windows app, you might want to give that a look-see.
That's my $0.02
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications. It's the new math! 421 == 156 !
|
|
|
|
|
I know MFC sockets are not ideal. But they work well for me, with the exception of this one problem. Otherwise, 30-35 clients even on Win98 and server is absolutely ok...
Yes, I use separate thread for each fike transfer, that's why I can't understand this behaviour...
Is it better to use CSocket or CAsyncSocket ?
Standa.
|
|
|
|
|
s_k wrote:
Server gives no response and the machine where the server is running is totally frozen up. With one exception - file transfer that I've started before, is going on well...When I kill the connection from client, server is ok again (as well as the whole OS).
Sounds pretty odd. I think you need to give details about your socket use.
Do you use CAsnyncSocket (not CSocket)? Do you run sockets asynchronously in one thread context? Check which part is locking up your server, is it really socket core (winsock <-> application messages) or your GUI (application <-> GUI messages)?
|
|
|
|
|
I use my own class derived from CSocket, is it better to use CAsyncSocket ? I start separate working thread for each transfer, so I can't understand why one socket blocks whole OS...
|
|
|
|
|
s_k wrote:
I use my own class derived from CSocket, is it better to use CAsyncSocket ?
I would use CAsyncSocket or something else (but NOT CSocket).
s_k wrote:
I start separate working thread for each transfer, so I can't understand why one socket blocks whole OS...
There are different socket concepts, the possible alternatives are:
a) blocking servers (handling only one request at a time, then wait again blocking)
b) threaded servers (handling simultaneous requests, one thread for every new socket).
c) asynchronous server (handling simultaneous requests, one server thread will handle all sockets - CAsyncSocket will cover this)
The server model always depends on application requirements.
|
|
|
|
|
But when I have the second case (threaded server) and start separate thread for each transfer, it is better to use CSocket, isn't it ?
|
|
|
|
|
s_k wrote:
But when I have the second case (threaded server) and start separate thread for each transfer, it is better to use CSocket, isn't it ?
Are you sure you want this? Multiple threads means using IPC or mutex or even more logic to avoid deadlocks or destroying your shared data. CSocket + multiple threads for incoming sockets is the worst of all combinations/possibilities IMHO.
|
|
|
|
|
But it works perfectly on all platforms, under extreme utilization...This problem only appears on very weak machines (32MB RAM) and only on Win95/98...
|
|
|
|
|
s_k wrote:
But...
you opened the can of worms, good luck with it!
|
|
|
|
|
I'm trying to move my code that compiles and links fine on VC6 to VC++ .NET. When I try to link a DLL that uses another custom DLL, I get a bunch of LNK2005 linker errors related to a new CStringT<> class, like:
"public: __thiscall ATL::CStringT > >::CStringT > >(char const *)" (??0?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@QAE@PBD@Z)already defined in CFGCoreUI.obj
where LeadHppD.dll is used by the other DLL containing the CFGCoreUI module. I have experimented with project options, but it has got me nowhere as yet.
Merry XMas to everyone here,
Bartosz Bien
|
|
|
|
|
|
Hello,
I've used WS_EX_LEFTSCROLLBAR and WS_EX_RIGHT and WS_EX_RTLREADING extended styles to make right aligned combo box and a left scrollbar in left !
It works fine on NT (Win2000 or WinXP) systems, But it doesn't work on Win98 Arabic
What's wrong ?
How can i fix it ?
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hi dear,
I'm looking for an article or sample, demonstrates using Office xp(2000) Chart in a VC++ or C# project.
Thank you in advance.
|
|
|
|
|
Hi there,
I have a question for understanding the MFC message routing mechanism. Can I describe the purpose of PreTranslateMessage() as following?
"hey window, I have a message. Do you want to handle it or prevent others to handle it?" - "Hm I think about it" - "hey and window, you might not get it via your normal message handlers if you are not designed to get it, catch it now if you need."
Notes: I found out that sending a message directly to a window does not invoke PreTranslateMessage(). Also in some cases message handler seams not to be called (e.g. a CDialog wouldn't normaly get keyboard messages in OnKeyDown() ), strange.
So, I put my stuff into normal MFC message handler and sometimes catch & forward some messages from PreTranslateMessage() . Is that a good idea?
Thx for a short feedback, Moak
|
|
|
|
|
You are right. It's better to use normal message handlers. PreTranslateMessage is used in special cases when standard message handler doesn't work - for example, to handle all keyboard messages in dialog.
|
|
|
|
|
I create a regular dll and implement certain function in it. Then i create a sample program that uses that function from respective dll. But the problem is that i need to distribute dll with my exe otherwise program not works.
Is it possible that i statically link my dll with program in similar manner we statically link MFC dlls. Condition is that I only have dll and lib but not source code.
|
|
|
|
|
Shah Shehpori wrote:
Is it possible that i statically link my dll with program
No, because DLLs don't work that way. Redo your project as a static library, which will build a LIB file. You can link the LIB into your EXE.
--Mike--
If it doesn't move and it should: WD-40. If it moves and it shouldn't: duct tape.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
One more thing, suppose i am calling a function residing in a dll, will it make any speed/performance difference as compared to calling the same function present inside the exe ?
|
|
|
|
|
Shah Shehpori wrote:
ill it make any speed/performance difference as compared to calling the same function present inside the exe?
The call to a static LIB might be minutely faster, because it doesn't have to go through an import table jump instruction, although it's nothing a person would notice.
--Mike--
If it doesn't move and it should: WD-40. If it moves and it shouldn't: duct tape.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
hi,
1>how to remove keys.
2>how to add sub keys and remove them
3>how to access the subkeys
thanx if even read
Brad
|
|
|
|