"EIO=3&transport=polling&t="
A Full Example :
https://google.com/socket.io/?EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p
here what is use of transport = polling and what t sands for ? and Sid?
nb: if it's not common for all socket io server let me know.
I need a simple explanation for the socket io polling, t and Sid sands for.
If you clone repositories like https://github.com/miguelgrinberg/python-engineio, https://github.com/miguelgrinberg/python-engineio, and https://github.com/socketio/socket.io, then search the codebases, you'll find a handle_request function in server.py, where you may interpret the code and read the code comments. It indicates that https://google.com/socket.io/?EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p may be interpreted as parts of a URL as follows:
https://google.com/socket.io/ is the socket.io scheme/host/path for handling HTTP requests
EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p are the query string parameters that are preceded by a question mark ?
query string parameter key EIO is provided to represent the Engine.IO protocol version used by the client, which has a value of 3 in the example, so the Engine.IO web server determines whether that's a compatible version or not
query string parameter key sid is the unique session id (see function generate_id) that is used to store the socket object for that session
query string parameter key transport is provided with a value of polling, so the web server will check that its a valid transport (i.e. either websocket or polling). See here for more info https://socket.io/docs/v3/how-it-works/
I also couldn't determine what query string parameter key t means, even the unit tests only focus on testing the query string parameters EIO, sid, and transport, but not t
Related
I'm using Smack with android chatting applications and recently I have updated Smack to version to 4.3.0 and getting some error in fabric. It is a NullPointerException inside of Smack:
Fatal Exception: java.lang.NullPointerException
Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
java.util.concurrent.ConcurrentHashMap.get (ConcurrentHashMap.java:772)
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
org.jivesoftware.smack.roster.Roster.getOrCreatePresencesInternal (Roster.java:388)
org.jivesoftware.smack.roster.Roster.access$1100 (Roster.java:94)
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
org.jivesoftware.smack.AsyncButOrdered$Handler.run (AsyncButOrdered.java:121)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
java.lang.Thread.run (Thread.java:818)
"Use the source, Luke (and study the relevant open standard)" Obi-Wan Kenobi
Smack is open soure, so let us look at the source: One interesting part is
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
which reads
Map<Resourcepart, Presence> entityPresences = presenceMap.get(entity);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L374
We also find that presenceMap is declared as follows
private final Map<BareJid, Map<Resourcepart, Presence>> presenceMap = new ConcurrentHashMap<>();
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L168
So it is a ConcurrentHashMap, which matches with the stacktrace. It is obvous that entity above is null, which is the cause of the NullPointerException.
Now we need to walk the call stack up (or down, depening on your point of view), to determine where entity origins from. Here the interesting part is
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
which reads
userPresences = getOrCreatePresencesInternal(key);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
so enitty is key here. Which is declare and define just a few lines above
final BareJid key = from != null ? from.asBareJid() : null;
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
So in case from is null, keywill also be null. Which later causes theNullPointerException. Looking at the code, we find that this is caused by a presence XMPP stanza without a from` attribute set.
The question is now if those stanzas are legal in XMPP. To determine that, we need to have a look at the specification. The relevant part is [RFC 6120 § 8.1.2.1 4.],1, which states
When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (localpart#domainpart).
So a missing 'from' attribute is generally allowed and is equal to the "account's bare JID".
Now the question is: Are there any presence stanzas specified send from the server to the client which do not have a 'from' attribute? I could not find any while reading the related RFC 6121. And I am not aware when this should ever happen (I possibly could be missing someting). But right now this appears to be a bug in the entity which creates those presence stanzas, which is the used XMPP server implementation.
(What XMPP server implementation do you use?).
Help me track the status of a specific port: "LISTENING", "CLOSE_WAIT", "ESTABLISHED".
I have an analog solution with the netstat command:
local command = 'netstat -anp tcp | find ":1926 " '
local h = io.popen(command,"rb")
local result = h:read("*a")
h:close()
print(result)
if result:find("ESTABLISHED") then
print("Ok")
end
But I need to do the same with the Lua socket library.
Is it possible?
Like #Peter said, netstat uses the proc file system to gather network information, particularly port bindings. LuaSockets has it's own library to retrieve connection information. For example,
Listening
you can use master:listen(backlog) which specifies the socket is willing to receive connections, transforming the object into a server object. Server objects support the accept, getsockname, setoption, settimeout, and close methods. The parameter backlog specifies the number of client connections that can be queued waiting for service. If the queue is full and another client attempts connection, the connection is refused. In case of success, the method returns 1. In case of error, the method returns nil followed by an error message.
The following methods will return a string with the local IP address and a number with the port. In case of error, the method returns nil.
master:getsockname()
client:getsockname()
server:getsockname()
There also exists this method:
client:getpeername() That will return a string with the IP address of the peer, followed by the port number that peer is using for the connection. In case of error, the method returns nil.
For "CLOSE_WAIT", "ESTABLISHED", or other connection information you want to retrieve, please read the Official Documentation. It has everything you need with concise explanations of methods.
You can't query the status of a socket owned by another process using the sockets API, which is what LuaSocket uses under the covers.
In order to access information about another process, you need to query the OS instead. Assuming you are on Linux, this usually means looking at the proc filesystem.
I'm not hugely familiar with Lua, but a quick Google gives me this project: https://github.com/Wiladams/lj2procfs. I think this is probably what you need, assuming they have written a decoder for the relevant /proc/net files you need.
As for which file? If it's just the status, I think you want the tcp file as covered in http://www.onlamp.com/pub/a/linux/2000/11/16/LinuxAdmin.html
I am building a RESTful API for retrieving and storing comments in threads.
A comment thread is identified by an arbitrary URI -- usually this is the URL of the web page where the comment thread is related to. This design is very similar to what Disqus uses with their system.
This way, on every web page, querying the related comment thread doesn't require storing any additional data at the client -- all that is needed is the canonical URL to the page in question.
My current implementation attempts to make an URI work as a resource by encoding the URI as a string as follows:
/comments/https%3A%2F%2Fexample.org%2Ffoo%2F2345%3Ffoo%3Dbar%26baz%3Dxyz
However, before dispatching it to my application, the request URI always gets decoded by my server to
/comments/https://example.org/foo/2345?foo=bar&baz=xyz
This isn't working because the decoded resource name now has path delimiters and a query string in it causing routing in my API to get confused (my routing configuration assumes the request path contains /comments/ followed by a string).
I could double-encode them or using some other encoding scheme than URI encode, but then that would add complexity to the clients, which I'm trying to avoid.
I have two specific questions:
Is my URI design something I should continue working with or is there a better (best?) practice for doing what I'm trying to do?
I'm serving API requests with a Go process implemented using Martini 'microframework'. Is there something Go or Martini specific that I should do to make the URI-encoded resource names to stay encoded?
Perhaps a way to hint to the routing subsystem that the resource name is not just a string but a URL-encoded string?
I don't know about your url scheme for your application, but single % encoded values are valid in a url in place of the chars they represent, and should be decoded by the server, what you are seeing is what I would expect. If you need to pass url reserved characters as a value and not have them decoded as part of the url, you will need to double % encode them. It's a fairly common practice, the complexity added to the client & server will not be that much, and a short comment will do rightly.
In short, If you need to pass url chars, double % encode them, it's fine.
I'm pretty new to Lift, and one of the things I've been trying to find is how to, in the context of a snippet, find the '#' in the current page's URL. So if a user visits http://www.example.com/some/path/page#stuff then I would like to extract "stuff" from that. I've been googling and searching the API docs and have yet to find anything for this.
I don't think the part behind the # ever gets sent to the server in the first place.
That's what wikipedia has to say about it:
In URIs a hashmark # introduces the
optional fragment near the end of the
URL. The generic RFC 3986 syntax for
URIs also allows an optional query
part introduced by a question mark ?.
In URIs with a query and a fragment
the fragment follows the query. Query
parts depend on the URI scheme and are
evaluated by the server — e.g., http:
supports queries unlike ftp:.
Fragments depend on the document MIME
type and are evaluated by the client
(Web-browser). Clients are not
supposed to send URI-fragments to
servers when they retrieve a document,
and without help from a local
application (see below) fragments do
not participate in HTTP redirections.
I don't think the part behind the #
ever gets sent to the server in the
first place.
You are correct, sir. That is the entire point of the hash.
Dylan, you could do something from the Javascript side:
$.ajax( { data : { fragment : window.location.hash ...
Say you have a mapserver-url like this: http://host/cgi-bin/mapserv?MAP=/path/to/mapfile.map&
Is a WMS specified in this way conform to the OGC WMS-specification? Some say the map-parameter is a vendor-specific parameter, but you also could see it as part of the URL-prefix for this service (ending with ? or & as specified, it's an & in this case). What do you think, is that compatible to the specification or not?
The OGC WMS 1.1.1 (Section 6.2.2)and 1.3.0 (Section 6.3.3) specifications are fairly clear regarding this topic:
An Online Resource URL intended for
HTTP GET requests is in fact only a
URL prefix to which additional
parameters are appended in order to
construct a valid Operation request. A
URL prefix is defined in accordance
with IETF RFC 2396 as a string
including, in order, the scheme
(“http” or “https”), Internet Protocol
hostname or numeric address, optional
port number, path, mandatory question
mark “?”, and optional string
comprising one or more server-specific
parameters ending in an ampersand
“&”.
As long as the online resource URL finishes with an "&", it should adhere to the WMS specification