Is there any way/trick/algorithm that allows me to know what kind of data is coming via socket? I can send both text and files via socket, but I wonder what I'm getting to treat differently.
Any idea?
Is there any way/trick/algorithm that allows me to know what kind of data is coming via socket?
No there is not, and it should be obvious that this is impossible. It's perfectly possible for a binary file and a text file to be identical at the binary level. In which case, how could you distinguish between them.
Sockets are simply a communication layer. It is up to you to determine the protocol for that communication.
There is a trick, exactly that. Unix command 'file' has a lot of heuristics built into it, which allows it to make a very educated guessess regarding random file contents. You can employ it by, for example, saving your data into a temporary file on disk and running file on it. Of course, it is non-binding, but file is good at what it does.
Related
I'm trying, finally, to understand eBPF and maybe use it in an upcoming project.
For sake of simplicity I started with reading bcc documentation.
In my project I'll need to send some data over network upon some kernel function calls.
Can that be done without sending the data to userspace first?
I see that I can redirect skbs from one socket to another etc., and I see that I can submit custom data to user space. Is there a way to get the best of both worlds?
EDIT: I'm trying to log some file system events to another server that'll collect this data from multiple machines. Those machines can be fairly busy in some situations. It should be real time and with low latency.
I'd love to avoid going through userspace to prevent copying the data back and forth and to reduce sw overhead as much as possible.
Thank you all!
It seems this question can be summarized to: is it possible to send data over the network from a BPF tracing program (kprobes, tracepoints, etc.)?
The answer to that question is no. As far as I know, there are currently no way to craft and send packets over the network from BPF programs. You can resend a received packet to the network with some helpers, but they are only available to networking BPF programs.
I'm writing an application that needs to send data to a socket and receive data from the socket.
I know how to do this; I've done it several times before it other apps.
Unfortunately, the only documentation I have for the server I need to communicate with in the current project is in the form of a JavaScript file that uses some library called "Socket.IO". I am not familiar with this library (or JavaScript for that matter).
The JavaScript code contains statements such as "io.connect" with a parameter that looks like a web site URL, as well as multiple "emit" statements that have at least two parameters each. I need to know exactly what these statements are doing in terms of: what host and port is it connecting to? What bytes is it sending to the socket?
Where can I find this information?
Thanks,
Frank
I am currently working on xmppframework, Requirements are to transfer the file between two iPhones. I searched for XEPs and found 0065 and 0096
XEP-0065 says:
XMPP is designed for sending relatively small chunks of XML between
network entities and is not designed for sending binary data. However,
sometimes it is desirable to send binary data to another entity that
one has discovered on the XMPP network (e.g., to send a file).
Therefore it is valuable to have a generic protocol for streaming
binary data between any two entities on an XMPP network. The main
application for such a bytestreaming technology is file transfer as
specified in SI File Transfer [1] and Jingle File Transfer [2].
However, other applications are possible, which is why it is important
to develop a generic protocol rather than one that is specialized for
a particular application such as file transfer.
Please see the line in bold, its confusing me if file transfer XEPs are SI File Transfer(0096) and Jingle File Transfer(0234), then what is the purpose of this 0065 XEP? why people on net referring sep-0065 for file transfer?
In XMPP there are different protocols (XEPS) for file transfer. Jingle, Bytestreams, OOB, IBB...
The purpose of XEP-0096 is stream initiation. So its build on top of the other file transfer protocols to enable seamless file transfers.
So its used to agree on one of the above file transfer protocols between 2 clients for a transfer, and also for finding a fallback method if this fails for any reason.
Alex
XEP-0065 is for proxied file transfers: you will need such a proxy in your infrastructure, unless you use a public one.
XEP-0096 is much more complex, I wouldn't recommend that for a start, although I would recommend it if you later extensively use large binary transfers/exchanges, as Jingle is used for VoIP at least.
So Im trying to further my understanding of sockets, but I want to start out at the lowest level first (well in C, not assembly lol)
However most sites that I deal with use the SOCK_STREAM or SOCK_DGRAM. However I have read around on Beejs guide....but I don't know if that actually deals with RAW sockets or not.
I'll obviously need to call SOCK_RAW in my call to sockets, but theirs not really a WHOLE lot of information about it. And this is just for learning purposes, i always try to understand the root of whats going on in abstraction.
Thanks
Assuming you're using Linux, I would look at the man pages for socket and packet as a start. From here and after reading a few other man pages to figure out how to actually send packets on the wire, I'd install Wireshark and experiment with sending hand-crafted packets and using Wireshark to capture and analyze them. You can learn a lot about the different network layers this way and how you can tweak different values in various headers.
We need is to push sports data to a number of different client types such as ajax/javascript, flash, .NET and Mac/iPhone. Data updates need to only be near-real time with delays of several seconds being acceptable.
How to best accomplish this?
The best solution (if we're talking .NET) seem to be to use WCF and streaming http. The client makes the first http connection to the server at port 80, the connection is then kept open with a streaming response that never ends. (And if it does it reconnects).
Here's a sample that demonstrates this: Streaming XML.
The solution to pushing through firewalls: Keeping connections open in IIS
I would go with XML. XML is widely supported on all platforms and has lots of libraries and tools available for it. And since it's text, there are no issues when you pass it between platforms.
I know JSON is another alternative, but I'm not familiar enough with it to know whether or not to recommend it in this case.