I've recently taken some classes in networking (CCNA 1 through 4), so I understand most of the theory behind it all. What I'd like to do now is take that knowledge I have and put it into practice in the form of some small applications.
I've been reading through some articles on MSDN on how to do this, but they seem to only cover network programming at layer 3 or 4 and upwards, IIRC. What I'm looking for is some simple examples of how to deal with layer two connectivity (ie. framing) between hosts, or even just something simple like how to perform an Ethernet broadcast.
I have a little experience with C# and C++, so examples which use either of those languages would be great.
Thanks.
For Windows, have a look at WinPcap which provides low-level network access. The developer pack already contains some simple examples to get you started.
BTW, on Linux there are packet sockets.
You could use the eEx Network Library to write small apps (I have done the same thing during my CCNA).
It is an easy-to-use and object-oriented .Net programming library, which lets you go down to layer 2 and send out custom frames via WinPcap.
Frame types like Ethernet, ARP, IP, UDP, TCP and RIP are implemented, and as far as I know, these are protocols which occur during CCNA.
Tutorials in C# are available here, and if you want look at something in depth, like address resolution, you can always have a look at the source code, since the library is open source.
Very probably, you could study low-level network utilities on GNU/Linux systems, or also look into the kernel TCP or UDP or IP layers. But for instance, doing an Ethernet broadcast is something very low level, and not very useful. And real examples (usually coded in C, not C++) probably can't be simple because they have to deal with error handling.
Related
I want to study network programming, there’s a chapter named “networking” in “C# in a nutshell”, this chapter contains ‘WebClient’, ‘HttpClient’, ‘FTP’, ‘TCP’ and so on. But some body tell me to study WCF, I want to know what’s the relationship between WCF and c# networking programming, I remembered I have seen somewhere that WCF encapsulates network programming, it’s more flexible and convenient, but not efficiency. Does this mean the relationship between them like ado.net technology with orm? Which I should to study, network programming or WCF? Does c# network programming an obsolete technology?
Thanks
"network programming" usually refers to sockets, this is the lowest level of network communication and deals with pushing bytes on the network - all the other communication systems are built on top of sockets.
Most projects don't use sockets directly because there are simple higher level systems you can use but I think it's still worthwhile to learn the basics because it's not so complicated and it will help you deal with problems in those higher level systems.
The next level is WebClient and friends, those are relatively straightforward classes that implement a communication protocol on top of sockets (for example HTTP).
It's definitely worth your time to learn how to use those because they are simple and extremely useful (for example if you want to pull a file from the internet or communicate with a 3rd party service).
At the highest level you have WCF, this is an extensive (and in my personal opinion over-complicated and over-engineered) framework that gives you a class interface for an external network based service while trying (unsuccessfully) to hide all the communication details.
WCF is very popular in big organizations and "enterprise systems", so, if you want to get a job developing enterprise systems for big organizations learning WCF is a very smart career move.
So, my advice, start with sockets, learn just the basics - this will help you understand how things work under the covers (this will become very useful when you have to debug network problems).
Than move on to the higher level classes, write a simple program that uses WebClient to read a page from the internet so you are comfortable with the concept, don't bother
with all the advanced options, they are there and you can look them up later when you need them.
Learning just the basics of sockets and WebClient should take just a few hours, after that (if you want to work on big systems) learn how to use WCF.
Then you will have the WCF knowledge for your resume and you will know how to just get something over the internet with a few lines of code without using a gigantic framework when you don't need it.
If you want to study network programming you'll want to read about sockets and TCP/IP (and later on UDP if you want to stream or smaller packets). Sockets are the API that most OS:es uses to handle protocols like TCP/IP.
Your comparison is correct. WCF is a framework on top of the networking layer in .NET. Just as ORMs are frameworks on top of ADO.NET.
WCF is not the so called network programming. They are two concepts with some relationship.
Usually network programming means socket programming and TCP/IP. You are supposed to be familiar with protocols, such as HTTP, FTP, SNMP and so on. Then you can write programs that serve as protocol servers and clients. Network programming is still hot, though it is no longer that popular.
WCF is a framework for web services, which is HTTP only (mainly SOAP).
If possible, you should learn both or at least know of both.
Which programming language should I use to write an Instant Messenger?
Here are the goals:
should be able to handle many, many users (at least for proof of concept)
protocol should be based on json or maybe binary data. i guess json is easier to implement and extend. I don't want to use XML because of the overhead. I know it's not much data but it should be as fast as possible especially on slow networks (e.g. mobile).
users should be able to be logged in on multiple devices simultaneously
history should be saved server sided so it can be viewed on all devices
server should keep a lot of idle clients alive
file transfer (not quite sure on how to realize, maybe a different network socket so it does not block chat messages on client side)
MySQL auth
(No, XMPP is not an option).
I'm a web developer with good experience in PHP but that is not an option for this project. I also have experience with Javascript (mainly for websites), but it would be easy for me to work with node.js and I have little experience with C#.Net and could also write C#.Mono. The server I want to write should run on Linux. I have no experience with Java but if it's the best way I could learn it.
I've read much about node.js and that it's evented I/O is really good for network applications and web servers. But what about instant messengers? The main part is to save messages and proxy them to the other room participants, so it's "network".
I also thought about C# which offers asynchronous sockets which work with a thread pool afaik instead of a event queue.
I'm not sure which of them is most efficient in regard of an IM server.
It would be nice if someone could give me a hint. I know C++ would probably be the best way but I somehow don't really like that language and it's hard to learn.
You can do all this in any normal programming language (C#, Java, C++, etc...), as long as you're competent enough in that language.
Any of those solutions will do. You can write evented networking code in pretty much any language - and yes, it's pretty cool to use it in scenarios like this one.
If you want something that will give you some kind of framework for easier networking, I'd recommend trying Erlang, but it might be tough to learn for a single project. node.js might be tricky with regards to keepalives / resource management on dead connections and similar scenarios where you don't really get an event.
If you're already familiar with c#, using mono might be the safest / fastest thing for you. Apart from that - you can write anything in any language - just use what you're comfortable with (unless you actually want to learn something new).
I don't know why you wrote that jabber isn't an option, but if it's only the xmpp technology you don't want, why not use a typical SIP proxy/server? (for example OpenSIPS) It's got MESSAGE request handling, subscriptions, authorization (with db) and keepalives already available. You can scale / cluster / shard OpenSIPS in pretty much any way you want.
I've always wanted to learn TCP or UDP(I hear UDP sucks though) in C# but I can never find ANY tutorial that can teach it. I mean, I've googled tutorials to the point where the results aren't even relevant anymore. Almost every tutorial I've come across explains TCP as if I already knew it, or they introduce terms but never explain them. After a few months, I have made absolutely NO progress. Any help here?
Note: I am not a beginner programmer, I have experience making programs. It's just the TCP tutorials out there suck.
You're possibly searching with the wrong keywords. The keyword is sockets. The TCP/IP programming API is called sockets, on pretty much all platforms including .NET.
try codeproject.com
They have a lot of tutorials with pretty good code samples about TCP/UDP communication (among other things).
One of the many
I think it's difficult to find tutorials for TCP and UDP specifically because they are specific protocols (although very frequently used) and Microsoft are trying to abstract all these concepts so that your application is not dependent of the underlying technology.
Nowadays, you'll be advised to use Windows Communication Foundation (WCF); and you have a lot of resources from MSDN or the beginner's guide.
By the way, learning TCP cannot be done with a tutorial, but with a book focused on networking such as this one. If you do so, you'll also learn why UDP doesn't "suck"...
The reason there is no Cä# toutorial is because it is not needed. You basically ask "is there a course telling me how the rules are on streets when I drive a mercedes". Hint: there are the rules how to drive n streets, and theree is a manual for a mercedes car.
Or: There are books about the IP protocol, and then there is the .NET documentation how .NET implements this. If you ever want to be more than a junior in the field of programming then better get used to learn abstract concepts separate and do not expect a full "howto" for every simple step.
Now, TCP / UDP are fully separate items. They both extend TCP and they have very different uses. Saying "udp sucks" would be quite ignorant towards a lot of programs I know that would never work with TCP and require the fast and easy data distribution of UDP (which, cont´rary to TCP, also supports multicast). Most of my traffic counting in gb) external these days is UDP based because udp does not get stuck on a lost packet, and list packets can be easily requieried with a specialized higher level (application level) protocol. TCP has the really nasty habit of getting stuck up to 3 minutes when a packet is lost. Sometimes (like: financial data, voip) this is not really acceptable. Most programs love the easy handling of TCP, but it comes with a significant price.
UDP is a different beast.
however, I found this very useful as a starting point: TCP/IP tutorial
I've written some .NET-based TCP/IP posts on my blog.
They're not a tutorial; rather, they are a few articles on common mistakes. I'd recommend reading them after you understand the tutorials. I also list a couple of good TCP/IP books under the resources section.
I've got a Win32 C++ game side project and I'd like to create a C# process that can be dynamically attached. The C++ process could then send debug data to the C# process and the C# console could send debug commands to the C++ process. I know this can be done, but I'm not sure how to do it. Anyone know?
There are plenty of ways to communicate cross-process. For your purposes, I would recommend you use Sockets to communicate between the two, as this will also allow you to communicate between machines if you like; and the semantics of using Sockets are similar in both languages.
On the C# Side, you can get started with Sockets by using the Socket or TcpClient class in System.Net.Sockets. Also, you'll probably find it a little bit easier to implement the server / listening side in the C# process.
TcpClient Class # MSDN
Socket Class # MSDN
System.Net.Sockets Namespace # MSDN
On the C++ Side, you have two means of utilizing sockets, either via WinSock functions or Unix/POSIX style functions.
Getting Started with Winsock # MSDN
Winsock Functions # MSDN
Note that the WSA**** functions are the formal WinSock functions, and select/listen/bind/... are the traditional Unix/POSIX style ones. You can use one set or the other.
TCP Sockets are probably your best bet; but you may find that UDP allows you to get started quicker. Also, you could potentially do interesting things with UDP multicast. Don't forget to check your firewall settings if you use sockets.
Other possible means of communicating between the two involve varying amounts of work and domain knowledge that you may need to learn. Here's a brief outline with Pros and Cons.
Named Pipes
Pros: Excellent performance on the same machine, easy to control in C++.
Cons: Difficult to use across machine boundaries.
COM Application Server
Pros: Easy to consume on the C# side. Once created, easy to extend on the C++ side.
Cons: Can be difficult to debug, and it is tricky to add support to an existing project. Also prone to COM registration and debugging headaches. Difficult to learn to use across machine and user-session boundaries.
Shared Memory
Pros: Superb performance, easy to control in C++, moderately easy to control in C#.
Cons: Cannot be used across machines. Has quirks in sharing buffers across processes, though you can always create a buffer for each side, and make communication one-way for the buffers. This is tricky to use if you have more than 1:1 communication between your apps.
We are doing something very similar using named pipes in one of the projects that I am working on. Although I didn't work on the implementation it seems to be doing the job very well. The following link gives a good overview.
http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx
I have a very simple problem. I have an application which is written in Delphi 2007 for WIN32. It uses a C# DLL which is imported into the project through it's COM interface and a simple trick to avoid registering the COM object. But now I have a Java-generated .JAR file that I want to call from my application. And while I have access to the Delphi and the C# code, I just don't have access to the Java code.
I can do two things. Either I call the Java class from the Delphi code, which would then be called from the C# code which is called again from the Delphi code. Or I just call the Java code directly from C#. (Which is called from Delphi again.)
I know this is a complex setup. The Delphi application contains a GUI and some communication modules for some special hardware. There are no .NET drivers for these. The C# code is there to maintain database communication and includes some logic related to CardSpace and other security options. The Java class is a third-party encoding module which is created by an outside party which calculates a special hash code over data in the database and does some additional processing and which controls yet another piece of hardware.
Biggest problem: no network communications! It will run on a special computer which has no network hardware installed. It's a stand-alone Windows XP system. While COM, Java and .NET are okay, I cannot use any TCP/IP communications on this system.
This would be my next project if I accept it. Already, it's giving me a headache so I think I'll skip this chance, although it does have an interesting mixture of several different languages. I think I'll just tell them to invest a number of 6 digits to buy new hardware instead of spending an amount of nearly 5 digits for 28 days of my work...
A few details about the project that I can share:
The Delphi code is able to connect to a PBX system through a COM port which it uses to send faxes, send and receive SMS messages and to receive simple commands by just entering digits with a phone after calling in. A whole system has been written for this, all based on WIN32 code.
The Java code is a client-side module to communicate with a robotics system that monitors the environment, handles a few delicate objects and does constant measurements of those objects. It's in Java so it's platform-independent. The communication between the Java client and the robotic hardware is done through the network and the network hardware/drivers don't like additional chatter over this network. (Which is why it's disabled as much as possible. Not even Windows will get updates.)
The C# code is to collect the data from the Java module and to actually store this in-memory writing regular backups in XML, just in case something happens. It's to communicate with the Java module and a few other modules that handle the complex calculations that are written in a .NET compatible domain-specific language this customer developed themselves. These modules don't support COM, thus the c# wrapper.
The client now needs an operator to be near the hardware to manipulate the robotics. He can either upgrade the hardware, costing him quite a lot but it would give him better remote access which costs about EUR 250.000 to replace the ancient robotics and other hardware or he pays a few developers a tenth of that amount to get his current hardware to do the same. Personally, I think he should not be such a cheapskate but he just wants an estimate what the developers solution would cost him. The code changes aren't big since most of the functionality is already there. It's just combining it all without any TCP/IP communications that makes it more complex.
Basically, the instructions they want to give is to speed things up or slow down, send occasional reports and to send SMS warnings in case of problems. Now, they have an operating sitting next to the screen, drinking coffee all day while reading some newspaper or other magazines. And while that's fun for a few days, he's unable to find someone who wants to do this all the time, 24/7. (Yeah, they work day and night, including weekends.)
Basically, this is all I know myself. Haven't even seen the PC that it needs to be installed on but they have a few configured all in the same way so I can get one to experiment with, once this would be needed. (And it will be a Hell to debug too.)On a final note, I presented the cost estimates and came up with a high enough number to convince my would-be employer to do a hardware upgrade instead. More expensive but it would maintain it's reliability.
Because of this, this Q had just become academic...
Another option would be IKVM. It's a Java implementation for .NET. Please take a look at this related question, the answers there might help you.
JNBridge provides a Java-to-.NET bridge (and vice-versa). It's commecially supported, relatively cheap, and it works well. It's low-latency, and does not require TCP/IP or network communications. You don't need access to the Java code to call it from .NET through the bridge.
Regardless of whether there is any network hardware installed, it is likely that the standalone Windows XP system will still have local TCP/IP networking available. You can have programs listen on a TCP port on the localhost address (127.0.0.1) and other services connect to them to exchange information through any protocol you choose. HTTP with REST might be an appropriate choice.
This is likely to be a lot less painful that trying to integrate all those technologies together in one Franken-program.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. Hope it will help you.