This is more of a general quick question.
But in like C#,Python,C,C++.......etc
Are all the basic "Sockets" network programming essentially the same. Like do they all use the Berkley Sockets (i think thats what they are called) or does each language have it's own way of doing sockets.
Thanks
Sockets are platform-dependent, not language dependent. So, linux uses the BSD sockets alone, Windows offers both BSD sockets (used almost exclusively) and a M$ flavour of sockets (called WSA), dunno about others. It all boils to what is found under the hood - more exactly at the kernel level of the OS. The socket implementation found there will offer a first set of API in order to make them accessible to kernel/user space - usually through a shared object / dynamic linked library and thus "natively" supporting the c/c++ languages. All the other languages are relying on language specific bindings to those SO / DLL files offered by the OS natively for C/C++.
HTH
Sockets are basically the same in C, C++, Java, Ruby. They are slightly easier (because the build in classes handle the boiler plate) in higher level languages. If you can write Socket code in C, then you can do it anywhere if you have a reference to translate.
#Kellogs brings up a good point, Windows has their own Socket API which (typically) performs better (in my experiences) on Windows than the Posix implementations offered. The APIs are very similar. I would make the analogy of OpenGL to DirectX. If you really know one, then you can figure out the other with a reference.
Now a days we don't differentiate the language, the class library that can be accessed from the language and the underlying operating system. Here is my explanation
C,C++,C#,Java - Are just the languages has no specific support regarding the network programming.
Java class library, .Net Framework, C++ standard library - among this I think C# & Java provides some classes for network programming. C++ standard library does not provide any network programming classes (only iostreams for file, stdinput & strings are available). But BOOST library for C++ provides classes for network programming. I am not aware of the other libraries.
OS - The operating system proives a base api (mostly in C) that is utilised by the class libraries above. In case of windows it is the winsock api (WSA) and in case of unix it is the BSD socket api. I think windows also supports to some extent the BSD api so that the learning curve is less. But as #EnabrenTane said it is more than that.
Agree with kellogs above. Windows & most major POSIX-compliant OSs support the basic BSD socket API. In addition to the Berkeley socket, each platform provides additional proprietary API for performance & scalability enhancement. These extended APIs are not strictly confined to sockets only - they work on any I/O operations (i.e. disk files, named pipes etc.). For example, (in addition to traditional select() & poll()) Linux has it's own epoll mechanism, BSDs have kqueue, Windows has WSAevent*, WSAaAsync* and I/O completion ports APIs.
These differences are visible mostly in lower level languages like C, C++ or Pascal.
C#, Java, Python, Ruby et al. are somewhat "higher level" compared to C - they provide robust technologies to insulate you from the low-level APIs. Instead of fiddling directly with the bare-bones socket API, you can use the extensive run-time class libraries provided with each platform. For example, to write a TCP/IP server in Python, you could simply use the SocketServer class. Similarly in C#, you can use WebClient to downlad files of the net. In C++, you have the Boost library. Of course, there's nothing stopping you from using raw socket API directly in your app.
Related
Do interpreted languages such as Java and Python need an operating system to work?
For example, on a bare-metal ARM microcontroller, can an interpreter be installed such that we can have both compiled code such as C, and interpreted code such as Python working together, Or is an OS needed to support this?
Of course you can write an interpreter that runs on bare-metal, it is just that if the platform does not have an OS any run-time support the language needs must be part of the interpreter. To the extent in some cases that such an interpreter might essentially be an OS. That is if it provides the services to operate a system, it could be called an operating system.
It is not perhaps as simple as interpreted vs compiled. Java for example runs on a virtual machine and is "compiled" to bytecode. The bytecode is interpreted (or just-in-time compiled in some cases), rather then the Java source directly. In an embedded system, it is possible that you would deploy cross-compiled bytecode on the target rather then the source. Certainly however JVMs exist for bare-metal. Some support multi-threading through a third party RTOS, others either have that support built-in or do not support threading at all.
There are interpreters for cut-down subsets of JavaScript and Python that run on bare-metal microcontrollers. I am not sure about full implementations, but it is technically possible given sufficient run-time support even if not explicitly implemented. To fully support some of these languages along with all the standard and third-party libraries and frameworks a developer might expect, may require so much run-time support and resource that it is simpler to deploy and OS, so implementations for resource constrained systems are often subsets or have restricted libraries.
Java needs a VM - virtual machine. It isn't interpreted, but executes byte code. Interpreted would mean grabbing the source in run-time as it goes, like BASIC.
When Java was new and exciting around year 2000, everyone thought it would be the next big general-purpose language, replacing C++. The syntax was so clean, it was "pure OO" and not some "filthy hybrid".
It was the major buzz word of the time. Schools stopped teaching C and C++. MCU manufacturers started to make chips with Java VM in hardware. Microsoft made their own Java "standard". Everyone was high on the Java hype.
Then as the Internet hype as whole collapsed in 2002, it took the Java hype with it. In the sober hang-over afterwards, people started to realize that things like byte code, VMs and garbage collection probably don't belong on bare metal systems.
They went back to using compiled C for hardware-related programming. Or in fact they never stopped, since Java never quite made it there, save for some oddball exotic architectures.
Java remained used only in the areas were it was suitable, namely web, desktop and mobile development. And so it got a second golden age when the smart phone hype struck around 2010.
No. See for example picoJava, which is one of several solutions for running Java natively. You can't get closer to bare metal than running bytecode on the CPU.
No. Some 8-bit computers had interpreted languages in ROM despite not having anything reasonably resembling a modern operating system. The Apple 2 is one example. You could boot the system without any disks or tapes, and it would go straight to a BASIC prompt, where you could write basic (no pun intended) programs.
Note that an operating system is somewhat of a vague term when speaking about these days - these 8-bit computers did have some level of firmware, and this firmware did provide some OS-type functionality like access to basic peripherals. In these days, what we now know as an OS was more commonly called a "DOS" - a Disk Operating System. MS-DOS is one of them, as well as Apple's ProDOS. These DOS's evolved into our modern-day operating systems (e.g. Windows 95 was based on top of MS-DOS, while modern Windows versions derive from a separate branch that was largely re-implemented with more modern techniques), so one could claim that their ancestors are the closest they had to what we now call an OS.
But what is an interpreter but a piece of software?
In a more theoretical sense, an interpreter is simply software - a program that takes input and produces output. Suppose you were to implement a custom solid-state Turing Machine. In this case, your "input" would be the program to be interpreted, and the "output" would be the program's behavior. If "software" can run without an operating system, then an interpreter can.
Is this model a little simplified? Of course. The difference is a matter of degree, not nature. Add very basic user input and output capabilities (e.g. a TTY) and you have the foundation to implement all, or nearly all, of the basic functionality of a language such as Java byte code, Python, or BASIC. The main things you would be missing are libraries and whatnot that depend on things like screen manipulation, multiprocessing, and networking, but you could handle them with time too.
This is a copy of a post I've sent to the ZeroMQ mailing list. However, the question is raises it not specific to ZeroMQ, but more generally regarding the need for a 'mapping' layer over the networking functionality provided in WinRT to provide a more normal 'Berkeley Socket facade' for C++ code when compiling against WinRT:
Hi all, I've used ZeroMQ in a mobile app (see http://www.ibuzzedfirst.com ) previously, for the iPhone and Android versions, as those platforms support native/C++/Socket development, and therefore ZeroMQ.
For the WindowsPhone 7.5 (OS 7.1) version, I had to re-implement any required ZeroMQ functionality from scratch, as WinPhone 7.5 only supports C#, not C++ (it's effectively a C# Silverlight App). Also, WinPhone 7.5 only provides its own 'version' of Socket support ( http://msdn.microsoft.com/en-us/library/sb27wehh%28v=vs.95%29.aspx ) which only support Async versions of functions, e.g. ConnectAsync, SendAync, ReceiveAsync etc. However, the lack of C++ made this a moot point.
As such, for the WindowsPhone 7.5 version, I restricted the app to 'client' (Contestant) functionalty only, and didn't implement the 'server' (Quiz Master) part. This was because the client part of the app only sends and receives requests, replies and subscriptions to the server, whereas the server utilises the inherent multi-threaded multi-user functionality of ZeroMQ. It was (relatively) simple to recreate the ZeroMQ transport protocol/headers for client use, and use the WindowsPhone Socket support to provide comms.
Ok, now I'm looking at porting the app to WinRT on Windows 8. (The desktop/tablet version first - the Windows Phone 8 RT SDK isn't out yet, but will be similar). The good news is that C++ is supported in WinRT, yay! (Actually, it still isn't that simple, when writing C# only WinRT apps, you can compile for 'AnyCPU', as soon as you include a C++ portion, you have to build 3 different versions - x86/Win32, x64, and ARM versions, but that's a different problem).
Unfortunately though, like Windows 7/8 Phone, WinRT does NOT support 'normal' Berkeley Socket access, but instead offers its own 'version' of Socket programming, with discrete classes for different socket scenarios, e.g. StreamSocket for a connecting TCP client ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocket.aspx#methods ), StreamSocketListener for a bindable TCP server ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocketlistener.aspx#methods ), and DatagramSocket / DatagramSocketListener for the UDP versions. Furthermore, only async versions of all the methods are provided.
So it looks like, to get ZeroMQ to compile sucessfully on WinRT, I'm going to have to write a Facade layer that provdes a Berkeley Socket-like C++ interface, and underneath performs the necessary mapping to the version of Socket programming provided by WinRT.
Has anyone else started this journey or written a similar facade? Interested to hear everyone's thoughts, especailly as WinRT looks to quite a 'big thing'!
Though its far from complete or correct and has lots of bugs, but I have started this project here https://winrtsock.codeplex.com. Have not implemented any listen/accept as of yet
You might consider something like ACE. It provides slightly higher-level abstractions over sockets, and supports older windows embedded OSs such as WinCE and the like. It's open source, so you can try it out, hack it up to make it work and contribute back. Alternatively you can contact one of several commercial organizations or people that offer support and contract the work.
I am trying to evaluate some technologies for implementing a communication process between some Ada modules with some C++/OpenGL modules. There is an (Windows XP) Ada application which communicates with a C++ application using COM, but I intend to switch the COM to a new technology. Some suggestions came up, such as direct Sockets, DSA, Polyorb, Corba and DSS/Opensplice.
DSA appears to be just Ada -implemented (not sure)
Polyorb has its last implementation on 2006, according to http://polyorb.ow2.org/
Corba someone argumented that it could be not simple enough to justify its complexity for implementing simple applications
DSS/Opensplice appears to be just C/C++ implemented, so an Ada binding should be done. It also looks to be not very simple to be implemented too.
Personally I like COM, but due to the migration, I'd rather take the sockets option due to its simplicity, and the interface architecture could be implemented very easily.
So, what you think? Could you please comment about these technologies or even suggest other more?
Thanks very much.
A big factor in your choice is the size and complexity of the system you're reengineering. Is it a broadly distributed system with lots of complex messages? Is it a relatively small system with a handful of mundane message exchanges?
For small systems I used to just roll-my-own socket-based comm modules. Now, though, I lean more towards ZeroMQ (brokerless) or STOMP (text-based). And there's some Ada support for these, zeromq-Ada and TOMI_4_Ada (supports both).
While these handle the distribution mechanics, you would still need to handle the serialization of the messages into transportable form.
CORBA/PolyORB and DDS solutions are rather heavyweight, but are complete solutions. If you don't fear IDL and managing brokers, they can do well for large-scale distributed systems. Yeah, there may need to be some Ada bindings built, but if you can get C headers or a C API to bind to, it's typically not too bad if you focus on just binding the functions and data structures you require. Rather than creating a comprehensive binding, liberally employ opaque and void pointers (void_ptr, opaque_structure_def_ptr) for structs and parameters whose internal contents you don't care about.
we intend to switch the COM to a new (suported) technology, since COM is not more supported by Microsoft
Whoever told you COM is no longer supported is totally clueless.
While COM has undergone many name changes (OLE, COM, OLE Automation, DCOM, COM+, ActiveX, WinRT) and extensions over the past decades, it is the single most important technology for MS platforms: past, present and future. The .NET runtime uses COM extensively. Much of the Win32 API is written in COM, and the portions that weren't, will be in Win8, since WinRT components are COM objects.
Also take a look at AMQP (RabbitMQ for server), there seems to be Ada library available for it http://www.gti-ia.upv.es/sma/tools/AdaBinding/index.php.
If you could find binding for Ada, Apache thrift might also be a lightweight option. Maybe you could even write your own binding, it should not be more difficult that rolling something of your own over the sockets.
If you do go sockets route, than I would suggest ZeroMQ as "supersockets".
One more option for your list should be to use Ada's distributed programming support, and write C/C++ wrappers to interface your C++ program into it.
I don't know that its the best option for your needs, but if your Ada compiler supports Annex E, it should be on the list.
Since this post, AdaCore published PolyORB on GitHub with regular updates :)
I want to run Cross-Platform XMPP Instant Messenger. What Server-Side language should I choose?
There's also http://prosody.im/ which uses Lua. Their mission statement:
Prosody is a modern flexible communications server for Jabber/XMPP written in Lua. It aims to be easy to set up and configure, and light on resources. For developers it aims to be easy to extend and give a flexible system on which to rapidly develop added functionality, or prototype new protocols.
Prosody is licensed under the permissive MIT/X11 license.
If you want to use a XMPP server, take a look at Ejabberd(written in Erlang) or maybe Tigase(written in Java)
If you want to create your own, use:
Twisted Matrix, a Python framework to develop asynchronous applications
Erlang, a functional language designed with concurrency in mind.
Java with the NIO asynchronous library
Depending on how close to the XMPP spec you want to be, C++ might be an option but it will be quite challenging, as there is a fair amount of logic to implement :-)
If you want to optimize for speed, identify the bottlenecks of your application, and look into writing specific parts in C(XML parsing or string handling).
Can someone give me a clear, concise definition of the difference between a programming language and a framework? I have scoured the web and been unable to find an adequate definition.
For extra credit, is it possible for a language and a framework to become so inextricably linked that there IS no difference, or is there such a clear line between them that this isn't possible?
A language is syntax, grammar, semantics (and perhaps a core library) that implementers are required to support. A framework is a cohesive set of library code that together simplifies programming in any given language.
An application framework is the organizational structure of any application's code, including choices for conventions in files/folders, classes/functions, etc.
An application framework product is any tool that helps generate the framework for an application.
An application design pattern is any conceptual approach for organizing code at the application level.
An software language is a language-based tool that can be used to build applications, utilities, libraries, frameworks, etc.
A library is any extension in functionality to the native compiled functionality of a language.
A standard library is a library packaged with the language product itself.
An external library is a library outside of the language product itself and is either called remotely or installed locally.
A code-generator is any tool that dynamically generates permanent runtime code based on the developer's input.
Regarding the clear line between language and framework, i suppose you can count DSLs (Domain Specific Languages) as constructs that are both a Language and a Framework ( as it is a Framework in the original Language it is build upon).
Lisp is the only language i can think of now that may blur such distinction:
"The name LISP derives from "LISt Processing". Linked lists are one of Lisp languages' major data structures, and Lisp source code is itself made up of lists. As a result, Lisp programs can manipulate source code as a data structure, giving rise to the macro systems that allow programmers to create new syntax or even new domain-specific languages embedded in Lisp."
http://en.wikipedia.org/wiki/Lisp_(programming_language)
I hope i can explain using an example.
Dot net is a framework which consists of large libraries and supports many
programming languages.. C# is a programming language through which you can give
instruction to a machine mainly computer.. Now if your source code is in C#
you can use Dot net framework libraries and the source code which is written in other
languages..
At my point, a programming language looks like bunch of stuff (syntax,grammar, semantics etc.) which people are already combine them into one more convenient, more useful, easier to use, and more enjoyable - a framework, and I love to have a framework before start making a program.
I know some programming languages like C, PHP, ASP, Python, Java, and some frameworks like Yii, Zend, Pygame, Struts. All I see is there can be many frameworks built from a programming language, but a framework is built from only on programming language.
A programming language is a specified, standardized method of communication between the programmer and computer (in modern languages, technically it's between programmer and compiler, which "interprets" your code into simpler instructions the computer can work with). It is a pure abstraction that specifies its structure, syntax and semantics; implementations of the language are generally considered part of the environment in which the programmer develops, and incorporate the compiler and any virtual machine implementation.
A framework is a standardized set of pre-written code libraries designed to be used and reused by developers, and is again tied more to the environment. An environment is the intersection of the language, framework, virtual machine or runtime (an abstraction layer in which managed or interpreted code is translated from a machine-independent form into native code) and machine (the hardware layer on which native instructions are executed).