Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I think I summed it up in the title. Regarding the question, I have been evaluating my options for utilities that allow me to craft, capture, and analyze TCP/IP packets. I am very new to network programming and I am still learning as I go, but at this point, I want to write a program that establishes a TCP connection.
Here are my goals (long term to short term):
Deploy and code a system that can establish an ssh connection between two computers behind NATS given their local host names (i.e. feynman.home to feynman.work) and the IP addresses of their routers. I would also like to be able to guide the connection across a set of hops if possible/necessary.
No using third parties or closed source code of any kind. #
Rewrite (and possibly modify) pwnat in a "cleaner" format (i.e. using some well developed library for a high level language.)
Establish ssh connection between two hosts behind the same NAT (using my own code of course.)
Establish TCP connection between two hosts behind the same NAT (using my own code of course.)
I have managed to find netexpect which seemed very promising until it failed to build on my Mac OS X (my computer is going through a glitchy period right now.) Netexpect may well be the best option, but I have come across quite a few others (e.g. scapy and its perl and ruby implementations.) Many of these are not well maintained (e.g. scapy and its perl and ruby implementations.)
So, I thought it would be best to bring the question to stackoverflow (unless there is a better stackexchange I am not aware of.)
*Given the current state of my computer (don't ask) portability is important.
*I would prefer something well maintained/under active developement as to best assure I will have all the tools I will need for my short and long term goals.
*Finally, I would prefer something that uses an interpreted language for a host of reasons ranging from my experience to my preference.
#Yes I am fully aware there are easier ways. I want to do it my way because this just as much a learning experience as it is practical.
I know you are looking for a library on an interpreted language, but libcrafter is very easy to use. Is a C++ library for crafting and parsing network packets. On the future, it will support more protocols.
Most of what you described involving routing the connection between multiple hops/NATs - isn't done in the SSH client at all. It would involve having access to several network routers and setting up all those NATs in advance, then those translations would already happen automatically when the connection is routed through.
Are you talking about proxying your connections through multiple servers? That could be accomplished by a macro that logs in to server A, then automatically invokes ssh again from server A to get to server B and so on.
Could you describe in some more detail what you are trying to accomplish?
Edit: I just read the description of pwnat. That is incredibly proprietary (and won't work in every situation anyway, since many configurations block ICMP completely). If you really wanted to try it out, you'll probably be stuck with C/C++. I don't think Java or .NET gives you the kind of low-level flexibility that you would need to packet craft, for security reasons. Have you looked at Ostinato: http://code.google.com/p/ostinato/wiki/Downloads?tm=2 or Nemesis: http://nemesis.sourceforge.net/
Pretty much everything on windows will use winpcap and on *nix it will use libpcap.
While I haven't tried it, this might work: http://www.codeproject.com/Articles/12458/SharpPcap-A-Packet-Capture-Framework-for-NET
It says it SharpPcap handles interfacing with winpcap... so depending on what they implemented, or whether you can extend that functionality, you may be able to put something together.
Or, in java, you might be able to use something like this as a starting point: http://jpcap.sourceforge.net/
libtins is an open source, multi-platform, C++ library I've been developing for the past year. You can forge, sniff and interpret packets from network interfaces using it. It's very simple to use, and it provides a high level interface so you don't have to worry about endianness, internal protocol implementations, etc.
You can have a look at it at the library's website.
Related
im a university student and I've been tasked with creating a simple File Transfer Protocol using TCP between two machines.
I have very basic knowledge about sockets, and I've been using Linux for a bit. Is it possible to create two virtual machines on VirtualBox (linux machines) and have one be the server and the other be the client? Is that the right way to go about it?
Another question I have is for protocol specification. Is this something I specify in the client or server program or in a separate program?
Other than that, I would appreciate any useful resources or examples you can provide me as a starting point, as it's taking me a lot longer than I thought to really understand how to accomplish this through resources I currrently have. I apologize to any of you who feel this is an unproductive post but I am simply seeking any advice I can get from you more experienced programmers out there.
Thanks!
Is it possible to create two virtual machines on VirtualBox (linux
machines) and have one be the server and the other be the client? Is
that the right way to go about it?
You can do that, but to start with you might find it simpler to run the client and server programs both on the same host. There is no requirement that they must run on separate machines (virtual or otherwise).
Another question I have is for protocol specification. Is this
something I specify in the client or server program or in a separate
program?
The protocol specification is part of the documentation; it's not part of either program. Both programs will have to follow the specification in order to interoperate with each other properly, of course.
Other than that, I would appreciate any useful resources or examples you can provide me as a starting point,
Pointers to resources/examples are off-topic for StackOverflow, but you can google e.g. "TCP programming tutorial" or "TCP programming FAQ" or similar and you should find lots of content.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have the impression that sockets are just one of several ways that an application can communicate over the internet, maybe because of the wording in some tutorials I have read recently where it seems like sockets have been chosen as the most efficient tool out of many for the job.
Is this assumption right or do all networking applications use sockets on some level?
Edit: To clarify I'm looking for a practical answer. If I want to write some client/server program that will run on two of my computers running either Linux or Windows, should I always think sockets first (or higher level protocol that uses sockets), or are there other equivalents that may be better suited for the job than sockets.
It is operating system specific. Some (old, or academic) OSes provide weird APIs for TCP/IP, and some OSes don't even do any networking. IIRC, Gnu Hurd has something else than sockets (and probably Fuschia also has something else).
In practice, Berkeley sockets are nearly a de facto standard (this was not always the case, e.g. TLI), at least on Unix-like and POSIX systems (and probably on Windows also) and when programming in C (or related stuff, notably C++).
And you could use higher-level libraries, e.g. MPI, 0mq, or protocol specific libraries (for HTTP, libcurl on client side, libonion on server side, ....) etc ..... They are generally built above sockets.
do all networking applications use sockets on some level?
On some supercomputers, you can also have InfiniBand (and perhaps a variant of MPI using that hardware without sockets, but with something else). etc... Sometimes they have some InfinBand specific address family for socket ....
(It is more than ten years that I didn't access any supercomputer, so I could be wrong for the details)
BTW, some consortia like FIWIRE or AUTOSAR define their own networking APIs (for niche markets or specific industries).
(perhaps such consortia are defining an API above sockets; I don't know them well enough; you need to check)
See also the libraries mentioned near the end of this answer.
If I want to write some client/server program that will run on two of my computers running either Linux or Windows, should I always think sockets first (or higher level protocol that uses sockets),
Certainly yes in practice. And I would often consider using some existing free software library above Berkeley sockets.
I was wondering if I can implement bi-directional communication channel between 2 kext modules using sockets under the domain PF_SYSTEM. this method mostly used to communicate between driver and user-space agent..
In my particular case I've got one module based on IOKit and the other which is simple kernel module with start and stop callback functions and I'd like to pass some small messages between them..
Do you think this approach is suitable for my needs or there's other preferable way (shared memory ? mach ports ? )
EDIT, after digging a little deeper, maybe there's an option to export an API from one driver to the other by modifying the client driver plist file as follows.. is it possible ?
<key>OSBundleLibraries</key>
<dict>
<key>com.driver.server_driver</key>
<string>1</string>
This however, doesn't work because when i try to manually load the client driver after the server driver already loaded (visible from kextstat), I get the No kexts found for these libraries error.
Using messaging techniques normally used for IPC for communicationg between kernel extensions is unusual, as it's a lot more complex than taking advantage of the fact that they're running in the same address space anyway. I covered some of the details of this latter approach in my answer to your other question which you've obviously already seen, but I'm linking to for the benefit of others in a similar situation.
To answer your question: I suspect both ends of a system socket being in the kernel is probably not very well tested, and you could run into bugs in the kernel. The in-kernel public socket KPI is also quite fiddly: getting the buffering right is tricky, so I'd only use sockets if I absolutely had to, and it clearly isn't here.
My gut instinct is that Mach messaging would work more reliably and require less code, but again I think it would be quite unusual to use it in this way.
It's hard to give useful advice on exactly what you should do, as we don't know the reasons for the separation into 2 kexts, what their relationship is, what kind of communication is required, etc. There are many possible ways on how to exchange information, but whether they are a good idea will depend on the details of the project. (This sort of question isn't really suitable to Stack Overflow's format - this is the sort of problem for which a company will bring in an expert to consult. For a private project, you might have more luck on the Software Engineering Stack Exchange Site, where this sort of question is on-topic, although I'm not sure you'll get a good/useful answer. For a private project it's probably best you keep it simple and maybe combine the 2 kexts into one?)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 months ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Which of these technology suite for Multi user online game project?
Project requirements:
Able to handle 2k-5k user at any given time.
client library for iphone and android (native, no javascript).
client library for Microsoft Windows (most important), also for mac os x and linux.
Good documentation specially for mod development
Project is not open-source. So, can only use libraries with suitable license.
I can program in erlang and java as well, programming language isn't an issue.
I was looking at following server technologies like Openfire, Tigase, ejabberd and RabbitMQ.
All are good for my project but I want to know more about what suite my needs, AMQP or XMPP.
What AMQP offer specially for real time online games. Is it better option then xmpp?
A key difference between XMPP and AMQP is binary content. AMQP handles binary data just fine, and XMPP seems more designed for XML. Personally for online games I use Google Protocol Buffers for message formatting and parsing, and with their very small binary footprint, I'd be more inclined to use AMQP to deliver those messages.
But do consider what AMQP server you want to use. I've been bitten by using RabbitMQ for my AMQP server in the past. RabbitMQ does not have any flow control facilities, at all. So if your clients are sending messages faster than your server can consume them, buffers on the server can fill up and blow the server up. More recent versions of RabbitMQ implement flow control in an exceedingly coarse way: they halt all consumers in the system until memory clears up.
I've never tried zeromq; perhaps it'd be better for the things I've been using RabbitMQ for...
5K users doesn't tell me much about their behaviour, but if they all submited one request within the same 10 second window then let's say you'd be looking in the 500-1000 requests per second.
I've had Active/MQ running on my relatively low-powered lap-top easily handling 300 requests per second and so I'd happily recommend it here. You can also set up clusters of brokers and achieve horizontal scalability. You can use an http protocol (STOMP) or its native binary protocol. Lots of client API libraries also for C/C++, Java, JavaScript and others. There is some initial AMQP support.
You didn't mention any persistence requirement, but again I would have thought that most RDBMSs would suffice. That said, some of the document oriented and big-table type databases look interesting from a horizontal scaling perspective.
I've also found Apache Camel highly performant and I strongly recommend it. Camel is used to implement your logic layer.
I would like to ask a question about network communication.
The Question is:
A server uses the socket interface on the Lunix platform,
and a client uses Winock on the Windows platform.
Can they communicate?
Explain briefly.
I guess the answer is NO.
I guess it is due to the compatibility between 2 different socket interface?!
But I am not sure my estimation is right or not.
So, I hope someone could give me some comments about this questions.
Thank you very much!
Not right at all.
The APIs are different, but both sockets create packets written to a standard format described in RFC 793 and lots of subsequent revisions and additions.
Follow that packet format, and implementations written for different platforms and in different languages will talk to each other.
This is the magic of the internet.